[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: linus talk on git

From: Bruce Stephens
Subject: [Monotone-devel] Re: linus talk on git
Date: Mon, 21 May 2007 14:41:33 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (gnu/linux)

Jack Lloyd <address@hidden> writes:


> Though as an aside: it appears that the changelog message is its own
> cert (looking at 0.35 here). Why is that? I would think it
> more natural to store that in a hash->string value (like file
> contents), and have the revision cert reference the hash. That way you
> avoid a sign/verify, and allows you to coalesce common log messages
> (just wrote a Perl script to go through the Subversion history on a
> repo at work, and found many duplicates like "first revision", "oops",
> "bug fix", "checkpoint", etc). Since you avoid the extra signature it
> should be an overall space win, too...

How do you avoid a signature?  Doesn't each revision still want at
least one signed cert asserting that a changelog belongs to that

I agree that regarding changelog messages (and perhaps other cert
values) similarly to file contents might be a win.  You could get
delta compression too, potentially.  I'm not sure how significant that
would be.

Probably more of a win to have a combined date+author+branch+changelog
kind of cert thing (since that's what you want on almost all
revisions) such as has been suggested before.

> Though then again, you wouldn't need to verify those certs anyway
> unless you were doing an `mtn log` or similar, a checkout wouldn't
> have any need to verify those (does it?)

I doubt if checkout or update look at anything other than the branch
(and testresult, and whatever's necessary for selector resolution)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]