[Monotone-devel] Re: linus talk on git

[Bruce Stephens]

Jack Lloyd <address@hidden> writes:

[...]

> Though as an aside: it appears that the changelog message is its own
> cert (looking at 0.35 cert.cc 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
revision?

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