Re: [Monotone-devel] Re: Workspace merge?

[Nathaniel Smith]

On Sat, Jul 14, 2007 at 02:17:52PM -0700, William Uther wrote:
> I can see what you're saying.  There are a bunch of different types  
> of conflicts, and I think
> some could be easily handled with renames.  Some seem harder to  
> handle with renames though.

The design work here has all been done already, it's pretty
straightforward... see http://venge.net/mtn-wiki/MergeViaWorkingDir
for the basic ideas (has some details sub-optimal), the
.workspace-merge.conflict1 branch has a sketch for what _MTN/conflicts
might look like concretely (not quite right), etc.  I second Zack's
recommendation to sit down and read {roster_merge,roster}.{hh,cc},
there are many ideas to make reasoning about this stuff easier.

> >>I would be very reluctant to put the conflict marker in the roster.
> >>That data structure is complicated enough.  I'd rather see a separate
> >>serialization of the conflict list in the roster_merge_result,
> >>indicating which changes to the workspace roster have been faked  
> >>up to
> >>remove conflicts.
> 
> I think it would be worthwhile to have conflicts in the roster as it  
> allows conflicted
> revisions in the database.  That means that 'merge' always  
> 'succeeds', and you get to fix the conflicts later.

No.  You are worrying about a version 2 feature, and we do not yet
have a version 1 implementation.  Version 2 is the enemy, worrying
about it distracts and complicates the already complicated problems we
have to deal with now, and is pointless besides, because we will know
enough more by the time we get to actually implementing version 2 that
probably everything we guess about it now will turn out to have been
naive and misguided.  (For instance, _my_ guess is that once we've
worked out how to write down a roster_merge_result structure textually
as _MTN/conflicts, then we'll realize that the easy way to "put
conflicts in the roster" is to just stick this file in the roster.
But that's just a guess.)

Or put another way: is getting this right the way you want worth
spending longer living with the current merge UI?  Or should we sit
down and get the basic features (that have 90% of the value) working
as soon as possible, and worry about the fancy stuff later?

-- Nathaniel

-- 
Eternity is very long, especially towards the end.
  -- Woody Allen