Jack Lloyd <[EMAIL PROTECTED]> 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. _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
