Re: Updated Issue 209 - support drop/modified conflict

Hendrik Boom <[email protected]> writes:

> Here we're discussing seriously the case I wondered about ages ago, 
> where you want to split a project into several projects, but later 
> decide to bring them back together.  You have the problen of decidint=g 
> which files to merge, and which files have more-or-less become different 
> files, both of which need to be kept.

But you only do that once; we're discussing a case where the conflict
can reoccur on many occasions as the project moves forward (the upstream
vs local case).

> What'd the overhead for deleted files now?  

none.

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

This is addressed in the sutures branch. The required information is
stored in the mark/merge cache, not in the revs themselves (the revs do
store the immediate parents of a suture). So it's still 'overhead', but
I'm not sure how much that matters.

>> Complicating things, I don't think it's a file specific decision. Maybe
>> there exist use cases where you want to ignore modifications from the
>> parent project, but at least want to see a warning, or even better a
>> real conflict, if somebody else from your project tried to modify the
>> file "before" seeing your deletion.
>
> 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?

Yikes. Let's not go there ...

> This whole discussion relates to the user-interface for merges.  
>
> 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?"  

You can do that now; check out both heads in independent workspaces,
and use your dev kit to compare changes and merge into one final
workspace, then commit that.

The mtn conflict process is a compromise on that; it makes all the
required information (rev ids, file ids) available, so a decent
front-end tool can help in the process, with only one workspace checked
out. See Emacs DVC.

> 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.

If that's because there are multiple revisions on each side, then zipper
merge (merging each pair of revisions, rather than just the heads) is a
good approach.

If it's because there are lots of files, the current 'mtn conflicts'
commands give you that.

-- 
-- Stephe