[darcs-devel] Re: [darcs #10] BUG: darcs misses conflict resolution

[David Roundy]

On Sun, Nov 07, 2004 at 11:54:51AM -0500, tomasz.zielonka at gmail.com via RT wrote:
> On Sun, Nov 07, 2004 at 08:31:16AM -0500, David Roundy via RT wrote:
> > This is a real bug, but will take some time to fix, and may be inherent
> > in the way we deal with merges (which I want to work on soon after 1.0.0
> > is released).  It doesn't look like a "dangerous" bug, although it could
> > be very frustrating.  It also doesn't look like it'll be a commonly
> > encountered bug.
> > 
> > So I think this bug may have to wait a bit before being fixed.  :(
> 
> It's OK as far as I am concerned. I've managed to find a workaround for
> this - record the first resolution, then the second, separately. I hope
> this will work again if I hit the same problem in the future :)

Certainly there will always be a workaround.  Unfortunately, there is no
guarantee that it will always be pretty.

> Hopefully this will be fixed some time in the future. RT will keep
> reminding us about the problem :)

Indeed.

> By the way, I would really like to understand the patch theory,
> including merges. I've already read the chapter of darcs.ps about patch
> theory. I don't understand everything yet, but perhaps that's
> understandable. Do you have any suggestions on how to best approach
> this topic? Reading, meditation, examples, reading code, ...?

Meditation is good... I came to understand the merger code (to the extent
that I actually *do* understand it largely by working out complicated
merges on paper.  It's an interesting excersize, and for moderately
complicated problems (say, merging two sets of two sequential patches),
it's definitely doable.  Dealing with mergers is never going to be simple
though, so definitely don't start with that.  Start with merges where
patches commute... those are hard enough.  Then you could move on to
mergers.

Working on (as in, writing) higher-level code is also helpful for
developing a feeling for how the theory works out.  Unfortunately, most of
the higher level code is now done using helper functions.  (Well, really
fortunately, as it's much harder to make mistakes this way.)  One example
of a feature that would be great to add, which would be doable for a patch
theory newbie, would be a smarter variant of trackdown which looks at
unrecorded changes, trying to find out what is the smallest (or
alternatively largest) set of the primitive patches shown by whatsnew which
passes (or alternatively fails) a given test.  The sorts of algorithms
needed are given in a paper called "Yesterday my program worked, today it
doesn't, why?", which you can look up.  Anyhow, that would be easy enough
that you could work it out for yourself (no merging involved), but it would
require dealing with patch dependencies, commutation, etc.

When you really want to understand mergers (i.e. when there are conflicts),
you need to sit down and read code with pen and paper, and do it yourself.
And then meditate some more.  :) When I was deep in the merger debugging,
would lay there working out merges in my head at night while going to
sleep.

But before tackling merge conflicts (non-conflicting merges are fine), you
definitely want to have a solid grasp of commutes, since that is where
everything is grounded.
-- 
David Roundy
http://www.darcs.net