[darcs-users] On merging

[David Roundy]

On Sun, Nov 28, 2004 at 02:49:28AM +1000, Anthony Towns wrote:
> David Roundy wrote:
> >I think the real solution to the merge conflict issue is two-fold.  We need
> >to keep track of merge conflicts in some more coherent manner than we
> >currently do, so that you don't see conflicts with conflict markers.  This
> >means maintaining something like pending which indicates which conflicts
> >are currently marked.  Then we need to make the UI display and handle
> >conflicts more nicely.  And of course, improving the conflict marking to
> >include dealing with problems such as the commonly-quoted "two files with
> >the same name" problem.
> 
> So one thing that seems sensible to me is to have the resolution to the 
> "two files with the same name" issue be "just use <foo's> file". But 
> afaics that doesn't let you pull patches to that file from foo without 
> continuing to get conflicts.

No, it doesn't, but that brings up an interesting possibility for a
conflict resolution.  I wonder if we could create a special "conflict
resolution" patch type that just chose one of the two (or three, or four)
conflicting sequences of patches? And that "knew" it was doing this, so
you'd stop seeing conflicts when pulling from that branch.  That would be
pretty fancy... :)

(Obviously, I haven't yet worked out if this would be possible.  You'd
certainly need some "interesting" commutation, and it wouldn't even be
conceivable without the new conflict management scheme I'm working on.)

With double-extra care, it may even be possible to have a conflict
resolution that allows both branches to be pulled from... i.e. does
something like renaming one of the two branches.

> Shouldn't Haskell let you match "(addfile x | move .* x) ... (rmfile x | 
> mv x .*)" pairs fairly efficiently (O(N^2) time at worst, but it should 
> by dynamically programmable to be linear), and then let you just commute 
> straight past them? Unfortunately (addfile x/y; move a/b/c x) pairs seem 
> like they can confuse the situation, but possibly not irrevocably.

Yes, something like this would be possible, in the case of your idea of not
allowing conflicts at all.  If conflicts were allowed, this wouldn't be
possible, since you'd have to deal with the case where the rmfile doesn't
exist yet.

The trouble with that idea, is that not all conflicts should be resolved by
an "inverse" patch.
-- 
David Roundy
http://www.darcs.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20041128/da74f59f/attachment.pgp