[darcs-users] Fwd: Towards a conflict-free revision control system.

Ian Lynagh igloo at earth.li
Mon Jan 19 19:09:04 UTC 2009


On Sat, Jan 17, 2009 at 05:26:58PM +0100, Jean-Philippe Bernardy wrote:
> On Fri, Jan 16, 2009 at 6:54 PM, Kari Hoijarvi <hoijarvi at seas.wustl.edu> wrote:
> 
> > Darcs 1 conflicts with identical changes , darcs 2 does not. I think darcs 2
> > does the intuitive good thing, but I haven't thought what are the
> > consequences when you unrecord such patches, I haven't used darcs2 enough to
> > run to such situation.  Time will tell, I use unrecord a lot when
> > prototyping.
> 
> I'm a bit surprised that darcs 2 decided to support confluence, given how
> that is controversial and poorly matches the operation-based model.
> 
> Can we have implementer's view on what's going to happen with unrecord?

darcs2's theory says:

Suppose A and B are patches with the same effect, recorded in 2
repositories, and you record C (that does not commute with A) in A's
repo. So we have two repos AC and B. Now merge them, to give ACB' (where
B' is a patch that says "I'm B, but I'm just duplicating another patch").

Then we can commute to any of these sequences
    ACB'
    AB'C
    BA'C
    BCA'
(where A' is analogous to B').

This does mean that if you have a repo
    AC
where intuitively C depends on A, then you can end up with
    BC
(by obliterating A' from BCA').

This means that the merge algorithm needs to be more complicated than it
would otherwise need to be. darcs2 does not implement this extra
complexity (darcs would fail, giving an error message, if it was
needed; in practice it's rare in the real world).

(FWIW, I disagree with this design decision, and camp doesn't behave
like that).


I hope that answered your question, but if not, let me know.


Thanks
Ian



More information about the darcs-users mailing list