[darcs-users] conflict misery....

[Tommy Pettersson]

On Sun, Jan 01, 2006 at 12:31:56PM -0800, Mark Lentczner wrote:
> 
> On Dec 31, 2005, at 1:50 AM, Tommy Pettersson wrote:
> >Your work in ~/working/product is parallel to the update in
> >[*1], and thus causes some conflicts resulting in "first
> >level" mergers which you cover with resolving patches in
> >[*2]. This is normal and quite harmless.
> 
> So we start with some base, B.  Then there are two patch sets, W0 and  
> B0 that are work in parallel.  So (in an informal syntax), this means:
> 
> 	~/base:    B + B0
> 	~/working: B + W0
> 
> Then I do the pull from ~/base, merging the parallel patches of B0 + W0:
> 
> 	~/base:    B + B0
> 	~/working: B + (B0 || W0)
> 
> Then I resolve some conflicts, with patch W1:
> 
> 	~/base:    B + B0
> 	~/working: B + (B0 || W0) + W1

Yes.

> >Your second update in [*3] is _also_ parallel to all your
> >work in ~/working/product _and_ to (parts of) the first level
> >mergers and your resolve patches.  This causes conflicts
> >with previous conflicts and produces "second level" mergers,
> >which are exponential in time with current darcs.
> 
> So, that is to say, the new work in base (actually grabbed from CVS),  
> B1 is this:
> 
> 	~/base:    B + B0 + B1
> 	~/working: B + (B0 || W0) + W1
> 
> Your point is that pulling B1 into working makes darcs do the really  
> hard work of
> 
> 	~/working: B + ( ((B0 || W0) + W1) || (B0 + B1) )
> 
> And that is just not going to be anything but exponential.  (I sort  
> of understand from the Patch Theory page that darcs is going to have  
> to unravel (B0 || W0) and then fiddle all about trying many  
> combinations of patches.)

Well, I don't understand the exact details, but a test run
with darcs gives:

  B + ((W0 || B0) || B1) || W1

This is a patch-order dependent representation.  I think
there are other combinations that describe the same situation,
but I don't know how to express it in a general way.

> >In this case you should pull all patches from ~/working/product
> >to ~/base/product before the second update in [*3] (or at
> >least the patches that conflicted with the first update
> >and their resolutions).  Then the record in [*3] will be
> >"on top of" the conflicts and resolutions and therefore not
> >be parallel and conflict with them when you pull the second
> >update to ~/working/product.
> 
> It seems you are suggesting that I should have pulled into base from  
> working:
> 
> 	~/base:    B + (B0 || W0) + W1
> 	~/working: B + (B0 || W0) + W1
> 
> And then update from CVS and let it mark the conflicts and fix the  
> conflicts there by hand, producing B1', which looks like the work for  
> B1 had been done after my merge:
> 
> 	~/base:    B + (B0 || W0) + W1 + B1'
> 	~/working: B + (B0 || W0) + W1
> 

Yes.

Hmm, another way could be to obliterate the conflict resolution
W1 before pulling B1.  That would make the total computation
less complicated.  The downside is you'll have to redo _all_
previous conflict resolutions, not only those that conflict
the second time.

> This is sort of sad - since it is basically saying that CVS is better  
> at handling this sort of conflict (or at least it is better at giving  
> up and simply asking me to handle it) than darcs.

A conflict _is_ of course something you have to resolve
manually, whether in darcs or CVS.  Darcs only has the extra
feature of no loss of information when resolving conflicts,
and therefore it can't "give up".

> For example, what if ~/base was my local copy of a central darcs  
> repo?  I wouldn't have the chance to modify B1 to make it look like  
> it happened after (B0 || W0) + W1.  I would have no option but to  
> pull it.  Which, as we know, won't really ever complete.

For now this lossless feature of darcs sometimes becomes
a miss-feature.

> Surely in large darcs projects, this sort of scenario comes up all  
> the time.  One can't always commit one's work to the common main line  
> before one has to grab the newest patches from main line.  And  
> sometimes, like in this case, two such grabs need to happen before  
> you can push.  What do folks do in this kind of case?

Instead of recording conflict resolutions as new patches,
you can amend your conflicting patches with the resolutions,
which brings them "on top" of main line.  It requires some
care not to amend pushed patches, and darcs can't currently
help mush.  You can keep a temporary tag that you unrecord
before pushing and tag anew afterwards, that depends on,
and thus protects, previous patches.


-- 
Tommy Pettersson <ptp at lysator.liu.se>