|
From: | Christof Petig |
Subject: | Re: [Monotone-devel] long RFC: "contexts" |
Date: | Thu, 27 May 2004 09:21:11 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux ppc; de-AT; rv:1.6) Gecko/20040414 Debian/1.6-5 |
graydon hoare schrieb:
these discussions, and some of the recent hacking (esp. on netsync) have been suggesting to me that monotone might benefit from having a "changeset" or "context" added as a "first class" (named) object.
Hmm, this basically is assigning certs to an edge instead of a manifest. This sounds like a really good thing to do!
(aside: yes, technically this could be more lightweight. really all we *need* to do for most of the "hard" goals is to make a context which contains parent context IDs and manifest ID, and then you can do all the rest hanging certs on the context ID. but I thought I'd cheat and kill multiple "efficiency" birds with one stone. feel free to reject the latter concept and argue that all we need is a simple context object)
I was not quite sold to context IDs (which simply adds _another_ unique ID for hash(id+[ancestry/timestamp])) unless I realized that they make edge certs (!) possible.
More ID namespaces will not make it more easy to understand monotones concepts but edge certs are the way other VC systems work. Perhaps designing them as edge IDs (hash(id+ancestry[+timestamp])) instead of hash(a big context text blob which even contains changelog) would be even more desirable.
Christof <old remarks and wild ideas>The benefit of your proposal is that ancestry, author, changelog and timestamp are combined so that they are easily assignable to each other. [A problem of the old schema was to assign author, changelog, ancestry and timestamp to each other once a loop occured].
Though there's no easy way to edit a changelog afterwards once the information is stored in the combined form [disadvantage of the combination].
Perhaps there is a way to handle content loops without inventing yet another ID (everything else is already present). A monster cert (author,changelog,timestamp,ancestry,branch) would do, wouldn't it?
</> <different issue>Since you redesign the cert system why not address a different problem: The fact that metadata modifications are not trackable (a subset of 'version controlled'). I have an easy proposal which might slow down things a little bit (proportional to the number of overrides):
Give a cert one additional field "replaces" which holds the ID of the certificate which is overridden (or hidden) by it (once it is considered approved). You might as well give each cert a modification timestamp.
</>
[Prev in Thread] | Current Thread | [Next in Thread] |