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

[Jerome Fisher]

Jon Bright wrote:

> Christof Petig wrote:
>
> > 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.
>
>
> Hm, well monotone doesn't already have an ID on this?  The lack of 
> ancestry hashes makes loops possible, and leads to various hateful 
> effects...

To my knowledge, there's currently no ID on this.

And there's no point having the ID if you don't store what it refers to. That's 
what a context is for.

(I know you know this, I'm clarifying it for Christof)

It's worth noting that contexts aren't *exactly* the same thing as edges. In 
the case of merges, they describe multiple edges.

It is possible to create "edge certs", by encoding the relevant parent into a 
cert attached to the context.

It's also possible to create "change certs", which refer to a specific change, 
by encoding the relevant parent and the position of the relevant change into a cert 
attached to the context.

It's also possible to create "file certs", by encoding the relevant path into a 
cert attached to the context.

Most of the time you want straightforward context certs, though.

> I'd actually be relatively in favour of not troubling the user with 
> manifest IDs at all.  Could not pretty much all monotone operations 
> which currently take a manifest ID operate equally well with a context 
> ID (/edge ID)?  Only one concept to explain to the user.  Am I missing 
> something?

Manifest IDs are useful internally for knowing immediately when two contexts 
have the same state. Perhaps a user might want to find all contexts with the 
same state, but this would be a very special case. Generally the user would 
only need/want to work with context IDs. That's really what they *intend* to 
work with now, when they use manifest IDs - the current concept is a bit broken.

> > Though there's no easy way to edit a changelog afterwards once the 
> > information is stored in the combined form [disadvantage of the 
> > combination].
>
>
> At least for my way of working, this is an advantage.  You can add 
> *more* changelog afterwards pointing out errors in the original or 
> expanding on its content, and have that in a second commit (or a cert). 
>  But the original is still there and everyone can refer to it. Allowing 
> editing of the original changelog introduces a non-versioned element 
> into the system, which for a versioning system, has to be a bad thing?

If two people do exactly the same change to the same ancestors, I think this 
should result in the same context ID. Certs should be a) bundled and b) 
versioned, but that's a separate issue.

Including the change/state metadata (author, changelog, etc.) in the context 
has implications that I think are undesirable. If you added more changelog to 
an old context, which has become the ancestor for new contexts, you'd actually 
end up with a new head. You also wouldn't see the new changelog when viewing 
information for the old context ID, unless analysing all child contexts 
(recursively) to see whether they're just a metadata update.