Thomas Moschny wrote:
On Monday 28 January 2008, Graydon Hoare wrote:
I think it's a good branch as they go in this sort of thing. I just ran
out of interest.
Sorry to hear that, but that's life, it seems.
It contains a variety of interrelated new code. Anyone
else is welcome to pick it up of course.
The changes are, primarily: [...]
- a sketch of the long-planned upgrade to certificates
Can you explain that a bit? Is this related to the idea of creating combined
certs consisting of a author/date/msg/branch tuple?
Yes, though there was a huge following thread in which most of the
issues were probed by others here :)
Pretty much my reasoning was:
- We need a new sort of 'branch' cert that points to a symbolic branch
ID rather than a string branch name.
- The 'branch' cert is really a 'commit' or 'approve' cert, so we
might as well gain some semantic clarity and cut down the amount of
crypto overhead (signatures are not small) by bundling the
commit/approve date, author(s), and comment fields. Of course these
would be separate from signing key ID and signing date. Authors
don't even need to be formally identified by keys. They can be
strings.
- It'd be good to shove a version number and/or algorithm ID in there
for vague hand-wavey future proofing. Not that one can ever be safe
from the future.
Perhaps this is embarrassing, but I thought 'suspend' certs had to do
with shutting down branches, and all the possible policy-branch designs
(even the most minimal) have a concept of a branch lifecycle, with a
revivable 'dormant'/'active' state and a sticky 'revoked' state.
-Graydon
_______________________________________________
Monotone-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/monotone-devel