Re: Updated Issue 209 - support drop/modified conflict

Hi,

On 06/08/2012 05:26 PM, Hendrik Boom wrote:
> What'd the overhead for deleted files now?

Nil. Niente. Nada. Zip. Zero.

> With the problematical 
> merges we're discuccing, we have to have some mechanism in place to 
> discover that a deletion has been performed in the distant past on one 
> of the nerging branches.

Yeah. That mechanism is called die-die-die: if a file exists in the
ancestor, but not on both legs, it must have been deleted on at least
one leg. And must therefore not be included in the merge (i.e. remain
deleted).

> Presumably that implementation mechanism would 
> suffice -- the file doesn't need to be mentioned in the manifest for us 
> to implement this model.

Well, we get the fact that at least one side has deleted the file.
However, that doesn't tell us (monotone) what to do in case of a
(conflicting?) modification on the other side. Does the user still want
to have the file deleted? Or does he change his mind and suddenly think
the change is worth resurrecting the entire file?

Monotone currently simply emits a warning, telling the user it's not
quite sure if keeping the file deleted is what the user wanted.

> It sounds like the same kind of problem.  Merging should just work if 
> both sides have the copying in their ancestry.

In that case, the user clearly applies a modification to only one of the
two files of the copy. There's nothing unusual there. No doubt that
change is *not* intended for the copy.

The question arises in case one side does *not* have the copy in its
ancestry:

   A        -- file 'foo' enters the stage
  / \
 B   C      -- B copies or duplicates 'foo' to 'bar',
  \ /       -- C (not knowing 'bar') modifies 'foo'
   D        -- D merges.


Do you expect 'bar' in D to contain the modification applied in C or
not? (Hint: there exist valid use cases for both possible answers).

> Otherwise, there are 
> decisions to be made, which might even involve line-by-line casuistry.

Asking the user to take this decision for every line that conflicts
seems unreasonably verbose to me. It's hiding the real question behind:
whether or not the copy in B was intended to be symmetrical or asymmetrical.

> It can even be a line-by-line decision.  You deleted this line on branch 
> A, but modified it on branch B.  It's a conflict.  What do you want?  Is 
> this really any different from the case with files?

Well, if you really want the file to vanish, you'd not only have to
re-iterate that decision once per conflicting modification, but for
every conflicting line of every modification! That doesn't sound like an
improvement to me.

As pointed out before, deleting a file doesn't necessarily equal to
deleting its contents. Just as renaming doesn't equal deleting and
adding the file elsewhere (and thus obviously doesn't conflict with
modifications, like deleting currently doesn't emit a full conflict, but
just a warning).

> When I'm faced with a merge, I'd sometimes like to be able to say, "Hey, 
> wait a minute, this takes serious thought.  Could you please put all 
> this stuff in my workspace without doing the merge, so I can pull out my 
> whole development toolkit ans work out what has to be done?"

I full heartedly agree here.

> I'd sometimes even like the possibility of doing the merge a bit at a 
> time, each time reporting progress to monotone until it's finally done.

*nod*  (However, representing partly merged revisions sounds tricky
enough. And I certainly don't want to start reasoning about merging
partial merges. Let alone conflicting partial merge decisions...)

Regards

Markus Wanner