monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict


From: Markus Wanner
Subject: Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Date: Mon, 04 Jun 2012 17:29:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4

Hi,

On 06/03/2012 05:57 PM, Stephen Leake wrote:
>> fixed in branch nvm.issue-209; dropped/modified conflicts are fully
>> supported.
> 
> I think this needs some review before I merge it to main.

I'm surprised issue 209 doesn't mention die-die-die merge. I consider
this a work-around to that problem. As such, it doesn't help in the rare
case of a "missing root conflict", for example. More importantly, it's
troublesome in cases involving multiple edits conflicting with one
delete. With "parallel" modifications:

    A        - file 'foo' exists
  / | \
M1 M2  D     - M1, M2: independent modifications to 'foo'
 \ /\ /      - D: deletion of 'foo'
  P  Q       - P, Q: merges, adding 'foo' under a new node-id


In case of M1 and M2 being sequential edits, the user would have to
"undelete" the same file several times, consider this:

    A
   / \
  M1  D
  | \ |
  M2  P
   \ /
    Q

If the user chooses to keep the file in both, P and Q, he'd end up with
two 'foo' files.

> In particular, the resolution process allows keeping the modified file.
> This is implemented as a drop and add, which is what the user would do.
> But it is done during a merge, so merge can now create new nodes.

That's why I'd argue that "fully supported" is an exaggeration, as the
"resurrected" file is disconnected from its previous versions, as you
pointed out yourself.

Ways of re-connecting it have been discussed before, but yeah, it's been
awhile since the last die-die-die discussion...

Regards

Markus



reply via email to

[Prev in Thread] Current Thread [Next in Thread]