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

[Jon Bright]

Jerome Fisher wrote:

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

(Just for the info of the list, Jerome works on the next desk to me)

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

Yep.  I didn't want to suggest removing manifest IDs - neither 
internally nor completely from the UI.  They're doubtless still useful 
for certain (to my mind, relatively obscure) operations.  I only wanted 
to suggest making the context ID the primary thing that the user works with.

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

Interesting point.  I guess it's clear that in that situation, both 
people's changelogs should be kept.  For this purpose, I guess I'd 
remove the changelog from the context ID and have it done with certs.

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

Well, I wouldn't allow changing of the changelog, only addition of certs 
clarifying, correcting or extending the changelog.  But another 
undesireable effect is that if two people make an identical change but 
provide a changelog that's a byte different, those two people end up 
with two different context IDs.  Were the context ID is the primary 
method of communication between the user and monotone, having two 
different context IDs for what's essentially the same change strikes me 
as a bad property.

--
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com