[darcs-users] RE: current status of darcs

[Stephen J. Turnbull]

Simon Peyton-Jones writes:

 > 4. At intervals, he pulls changes from the HEAD
 >    Puling these changes causes conflicts here and there, where he
 >    has modified the same code as in the HEAD.  But that's fine.  He
 >    fixes the conflicts and records.  The exact mechanism isn't
 >    important, but Joe ends up with a repository that has all the
 >    HEAD patches, plus some of his own
 > 
 >     He needs to do step 4 regularly, partly because he doesn't want
 >     to diverge too far (conflicts are easier to resolve earlier)
 >     and partly to get bug-fixes and features from the HEAD that he
 >     needs.
 > 
 > 5. Now he's ready to submit!  He does a final pull from the HEAD,
 >         to ensure there are no remaining conflicts, and then pushes
 >         to the HEAD
 > 
 > The trouble is that, unless I misunderstand, darcs simply does not
 > support this scenario, at least not for projects as big as GHC.
 > Step 4 doesn't work, and there is no viable work-around.

As far as I can tell, Darcs partially supports *this* scenario.
First, all the pushes *must* come after all of the pulls, and then the
branch is abandoned.  Second, there must be few iterated conflicts
(which I call the "ChangeLog problem", because all changes take place
at byte 0 in a ChangeLog, so every change results in an iterated
conflict).

I think one practical problem is that Darcs has no way to recognize
and automatically resolve iterated conflicts.  Eg, a very primitive
resolver is what git calls the "ours" merge: you simply declare that
in all cases of conflict between local branch and remote branch, the
local branch wins in this merge.  This has the effect of "sealing" the
local branch because the parent-finding algorithm will find the node
and treat that as the most recent common ancestor, and no iterated
conflicts (based on pre-merge conflicts) will occur in future pulls.

As I say this is very primitive, but what it does is to allow
development to continue, and then you must do a diff by hand at the
end to complete the merge.  But this diff is "small", as it will be
restricted to locations where conflicts were permanently resolved by
force and a new conflict arose.  These locations are genuine long-term
conflicts, because continuing development is occurring on both
branches, so probably you do want to review them just before the final
merge.  And, of course, history is preserved.

This does not address the pull-before-push issue, so I don't know
whether it would actually be useful to GHC Joe.  It shouldn't be that
hard to implement, though.

N.B. I may not be understanding how this works in git since the
operational model is quite different, and I am not able to implement
in Darcs so I haven't actually tried it.