Re: [Monotone-devel] long RFC: "contexts"

[Christof Petig]

[I edited this text multiple times so it certainly shows different views 
(which evolved over time)]

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.
</>