[darcs-users] nested mergers becoming more common

Tommy Pettersson ptp at lysator.liu.se
Fri Aug 12 12:33:29 UTC 2005


On Tue, Aug 09, 2005 at 08:57:53AM -0300, zooko at zooko.com wrote:
> 
> It seems like one to two new users per week have been showing up on the #darcs
> channel on Freenode asking why darcs has locked up.  Upon investigation, it
> usually turns out that they have nested mergers.
> 
> Someone really ought to write some notes on how to be forewarned, to detect and
> to correct this situation and post it on the Wiki.

I so wish I had time to write a page or two about this right
now, but I don't.  :-(

I think this is an important issue to deal with to not put
off new users trying darcs.  I also think that some of this
problem will always be part of darcs; darcs will theoretically
perform ANY merge, so there is always the possibility that
users, out of ignorance, build "parallelish" repos and
expect darcs to always handle it well, although some such
merges ARE going to take forever (sort of) unless darcs
breaks the so far known limits of efficient computability.
(Actually I don't know that for sure, but I would be very
surprised if it was not so).  However, darcs can currently go
into complex spin in situations where it shouldn't need to,
which the new conflictors are meant to fix.

I think there might be an unfortunate misguidance from users
experiences with other RCS:s when coming to darcs.  Most RCS:s
will merge in a destructive way; they will just sort of clash
the two versions together, using various complicated schemes
to get a decent result.  There is no question to whether
the merge will complete, just a question of how messy the
result will be.  Darcs is different.  It will really capture
the whole essence of the merge.  That's why you don't need
to bother with branch points and merge points and all that
stuff; you just pull and push, and darcs figure out the rest.
The figuring out can become very complex.

Say I do the same work in two parallel branches, but
independently and with slightly different changes, over
a time of three years.  An other RCS will quickly find the
differences between the two file trees and give them to me in
a merge where I can sort them out.  Darcs will examine each
and every little patch from the common starting point onwards,
carefully tracking whenever the same line was changed in the
two repos, even if the change is syntactically the same, also
keeping in mind if the line came from one of several previously
parallel changes.  The result (well, the theoretical result,
that is...) will be a perfect record of two parallel and
conflicting development lines.  A partial change (single patch)
coming from either one can later be unpulled from this mesh,
or a change from a third development line (conflicting or not)
can be inserted somewhere in the middle of it.  Darcs will
figure out how to do it -- if you can wait long enough.

I don't think new users expect darcs to be this serious
about merges.  And although you can be running darcs within
five minutes, it takes somewhat longer to develop a "feeling"
for how to restrict the use of branches to avoid this kind of
havoc -- especially since darcs won't do anything to stop you;
on the contrary, it will perform some amazing stunts as long
as they still fit within normal time/space.



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




More information about the darcs-users mailing list