Darcs understanding (Re: questions from a new bzr user)

[John A Meinel]

Jan Hudec wrote:
> On Thu, May 04, 2006 at 21:23:07 -0500, John Arbash Meinel wrote:
>> One thing I would like to mention about Darcs, which was one of the
>> show-stoppers for me. Was that it doesn't maintain an accurate history.
>> Because of the "theory of patches", when you merge someone else, it can
>> actually change the history of your branch.
>>
>> As an example:
>>  I committed patch "A, B, C" in my branch, and then I merge you, where
>> you committed patch "D". In bzr, this would show up as:
>>
>>   A
>>   | \
>>   B  D
>>   |  |
>>   C  |
>>   | /
>>   E
>>
>> My understanding of Darcs, is that it might decide to commute patch C &
>> D, so that you end up with
>>
>>   A
>>   |
>>   B
>>   |
>>   D
>>   |
>>   C
> 
> Actually no. What it does is generating a minimal partial ordering of
> the patches (under which B does not necessarily depend on A, C does not
> necessarily depend on either A or B and D does not necessarily depend on
> A). Patches don't depend on each other iff applying them in different
> order yields the same result.
> 
> After the merge, Darcs does NOT produce new revision. The revision of
> your tree is simply {A, B, C, D}. Any set of patches can always be
> merged, with the result possibly containing conflict markers.
> 

I thought there was an issue about not being able to get your history
back. I don't know if it just records the set of patches at the current
point, rather than the actual order that they were applied.

Maybe its just that darcs keeps track of the current state of the tree,
and not the history. Certainly not everyone cares about the history.

>> This also has deeper implications when it comes to revision integrity.
>> Because C might be changed by applying D, one cannot create a
>> cryptographic signature for C. Inherent in the model is that revisions
>> change based on what other revisions you have applied.
>> I believe the benefit of this, is that you have more conflict free
>> merges. The downside is a very large lack of stability.
> 
> You can't create cryptographic signature for C. That's not what you want
> to create cryptographic signature for, since C is a patch, but NOT a
> revision. A revision is {A, B, C} and {A, B, C, D} and you COULD create
> cryptographic signature for that (except I don't think darcs makes any
> provisions for it).

Not entirely true. Because when I commit a change, it certainly seems
like that change is something I would like to sign. Especially since
that is what other people are merging.

There is also a place for signing the complete snapshot like bzr does.
But since bzr includes the parent pointers, you can argue that it signs
the delta as well. (Though since we got rid of the parent sha1, we don't
really check the integrity of the deltas).

> 
>> I do believe darcs has a lot of very nice things going for it. And I
>> think we should keep and eye on it, and see what things we can
>> incorporate. But I thought you should be aware of something I considered
>> important, that I didn't see mentioned.
> 
> I didn't actually try darcs, but I think I understand the 'patch
> algebra' thing quite well. For one thing it does not actually give you
> full cherry-picking. Only independent patches can be picked. Though
> there would be a useful way to record proper reverse patch -- but I
> think that can be done with revision model bzr has as well.
> 

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060505/fd5a7da2/attachment.pgp