[darcs-users] Internals question: How to apply a merger patch?

[David Roundy]

On Sun, Nov 30, 2003 at 01:12:20PM -0800, Kevin Smith wrote:
> David Roundy wrote:
> >First, I'd like to point out that merger 0.9 patches are no longer created,
> 
> Ah. It would be nice if I could refuse to support them, or perhaps only 
> support whatever subset of them is needed to handle the darcs tree. Do 
> you have any rough idea how many 0.9 mergers are out in the wild?

Very few, I'd guess.  I think they went out of production around March or
May.  I'd say it's definitely worth considering just hardcoding the 0.9
mergers that show up in the darcs repo, at least as a start.  Obviously
that's a foolish thing to do in the long run, but it'll get you onto more
interesting stuff.  Actually, I've got a few 0.9 mergers in a repo at
work... hmmm.

I've considered adding a feature to repare to eliminate 0.9 mergers (by
converting them to an equivalent patch.  This would be a "dangerous"
operation, but not terribly invasive, and 0.9 mergers really are fossils
anyways (in that they won't work right if you merge a new change that
conflicts with them.

> Oh. I'm not used to haskell's 'case..of' details. You're saying that [x] 
> will only match a list containing exactly one item. Anything else 
> (including lists of zero or multiple items) will fall through to the 
> next case. Interesting.

Yeah, this is a case of haskell's pattern matching feature.  [x,y] would
match a two-element list, etc.  Similarly (x:xs) matches a list containing
at least one element, with the first element being bound to x and the rest
to xs (xs being a list).

> Ok. So the merger patch isn't used to _resolve_ a conflict--at least not 
> from a human standpoint. It merely merges two conflicting patches into a 
> conflict notification. Very interesting.

That's not entirely true.  A 0.9 merger *will* resolve a conflict if it can
see how--for example if both changes were identical.  Also, I think perhaps
it'll resolve a conflict when there are two line adds at the same
location (I don't remember for sure).

> So if I look ahead a patch or two in the darcs history, I should find
> another hunk patch where you manually cleaned up this conflict, right?

Yes.

> >Each patch sequence output by unravel corresponds to a different version
> >that got merged together.  So if three people make three different changes
> >to the same line, unravel of the final merger created would give three
> >possibilities.
> 
> Would a three-way merger be stored as a merger that contains a patch and 
> another merger?

Yes.

> What sequence of darcs commands would result in a three-way merger? I
> guess you would have to apply a merger that conflicts with the tree it is
> being applied to?

The easy way is to have three repos, each of which contain a single patch
(besides their shared context):

repo A:
hunk
-O
+A

repo B:
hunk
-O
+B

repo C
hunk
-O
+C

then from A you do

darcs pull B
darcs pull C

In practice a three-way conflict isn't all that common, but the more
developers you have working on a project, the more likely it'll be
(especially in makefiles).
-- 
David Roundy
http://www.abridgegame.org