[prev in list] [next in list] [prev in thread] [next in thread] 

List:       darcs-conflicts
Subject:    Re: [darcs-conflicts] any ideas how to force_commute
From:       David Roundy <droundy () abridgegame ! org>
Date:       2005-05-11 10:34:00
Message-ID: 20050511103355.GD16425 () abridgegame ! org
[Download RAW message or body]

On Tue, May 10, 2005 at 09:41:21PM +0200, Marnix Klooster wrote:
> >This gets us to the commute that we're wondering about--which is definitely
> >a commute that should fail unless "forced", when trying to commute [A,B]C.
> >Which means that you can't unpull "B" (which is now represented as [A,B]),
> >since it won't commute with C.
>
> I understand.  But *why* are you only force_commute-ing in case of a
> merge, and not in case of unpull-ing B in this scenario?  Because you
> want to avoid this difficult commute, or because you think such an
> unpull is strange and the user should be protected against it?  In other
> words, is "it won't commute with C" a statement of (mathematical) fact,
> a design decision, or a current limitation?

It's mostly a design decision.  I don't think it makes any sense to
force_commute on unpull--you'd be left with a patch that has a conflict
with nothing, and you'd have a user situation that doesn't make any sense,
so the user interface would be complicated.  What happens when I have a
bunch of patches modifying a file that was never added, because its
addition was unpulled?

In the case of merges, all the information is still there, and we can
reconstruct the original situation.  In the case of unpulls, we'll be
losing the information--some of it'll still be there in terms of
conflictors, but there's no way of knowing what other changes were
involved.

I also think there's an asymmetry to be exploited here.  There's a
fundamental difference between [A,B] and inv([A,B]).
-- 
David Roundy
http://www.darcs.net

_______________________________________________
darcs-conflicts mailing list
darcs-conflicts@darcs.net
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-conflicts
[prev in list] [next in list] [prev in thread] [next in thread]