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

Simon Marlow marlowsd at gmail.com
Thu Feb 12 09:22:33 UTC 2009

Ian Lynagh wrote:
> On Wed, Feb 11, 2009 at 09:43:58PM +0000, Simon Marlow wrote:
>> Ian Lynagh wrote:
>>> And what should it mean to cherry pick a patch without one of its
>>> dependencies? You get a patch that you can't apply?
>> Imagine cherry picking the patch with its dependencies, and then pulling 
>> in the inverse of the dependencies too.  That will result in a conflict, 
>> but in exactly the places you want: the places where the cherry-picked 
>> patch depends on a patch that you didn't want to pull.  Then you record 
>> a conflict resolution patch.
>> If this could be made to work, I think it would be a killer feature.
> So if we start with the repo
>     {A}                 (A is a megapatch)
> and someone else has
>     {A, B, C}
> (where C depends on B) and we want C but not B, then I was suggesting we
> "force-pull" C, leaving us with
>     {A}
> and unrecorded changes of C, plus the primitive patches in B that C
> depends on.

So that gives you a repo with no conflicts, but we've lost the information 
about which patch was pulled.

> I think you are proposing that we end up with
>     {A, B, C, B^}       (X^ means X inverse)
> and unrecorded changes marking the conflicts between B^ and C? That
> would also work, but personally I find it less pleasant. Mostly this is
> not for any good reason, although it does have the disadvantage that you
> can't easily later decide to pull B after all. On the flipside, it does
> mean that our repo knows that it contains C, which I means that we'll be
> able to pull in some patches that depend on C but don't conflict with
> the B^ patch.

I was vaguely hoping that it might be possible to do something sensible if 
B was later pulled.  You want B to somehow cancel with B^, and to conflict 
with your original conflict resolution patch (waves hands).  Also you 
probably want "something sensible" to happen if later you need to pull some 
other patch that depends on C.

The reason I'm attracted to this solution is because it retains all the 
information in the repo about what happened, so at least in principle it 
feels like the right thing.

> There's no reason we couldn't have both options available, of course.

Absolutely - and your approach looks less complicated to implement.


More information about the darcs-users mailing list