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

[Jan Hudec]

On Fri, May 05, 2006 at 06:54:02 -0500, John A Meinel wrote:
> Jan Hudec wrote:
> > On Thu, May 04, 2006 at 21:23:07 -0500, John Arbash Meinel wrote:
> > 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.

Well, the logic is defined so, that the set defines the content and order of
application does not matter. It does not remember how the set looked over
time.

> 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.

Yes, indeed, darcs does not track history in sense how exactly the tree
looked. Though you can tell it to record the particular state (something like
a label in other systems, but I don't remember how it's called in darcs).

> >> 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).

Well, in fact darcs provides tools for sending and applying gpg-signed
patches. Which implies there is a canonical representation of the patch that
could be signed (there is -- the form that applies to the minimal set of
prerequisites only). But I had an impression, that the representation can
change and that the repo does not keep the signatures around.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060505/b51aab67/attachment.pgp