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

[Jon Bright]

Hey,

We've just discussed this here.  Jerome and I are in agreement that if 
we were to be defining the data to be hashed for the purpose of context 
IDs, it'd look like this (conceptually, whether it's necessary to hash 
braces, colons and so forth is another matter):

manifest: <manifest-sha1>
edge: <first-parent-context-sha1> {
  renames: [<oldfilename>, <filename>] ...
  adds: [<filename>, <file-sha1>] ...
  dels: <filename> ...
  changes: [<filename> <file-sha1>] ...
}
edge: <second-parent-context-sha1> {
  renames: [<oldfilename>, <filename>] ...
  adds: [<filename>, <file-sha1>] ...
  dels: <filename> ...
  changes: [<filename> <file-sha1>] ...
}

We've:

 - renamed parent to edge
 - renamed patches to changes (though we're not sure about that name 
either)
 - clarified that the filename in "changes" is the filename *after* any 
renames have taken place
 - Removed the first <file-sha1> from the "changes" description.  With 
the clarification about which filename the changes are acting upon, the 
previous SHA1 isn't necessary - you know what SHA1 the parent's file of 
that name had, so you know what you've gone from, you just need to 
represent where you went to.
 - We'd clarify that the change types (renames, adds, dels) and (adds, 
dels, changes) are mutually exclusive - if a file appears in one of 
these, it can't appear in either of the others, for both groups of 
change types.

Additional to this, it'd be nice to store the version of the automerge 
algorithm that was used.  This doesn't need to be hashed (though it 
wouldn't harm to do so) - storing this would enable determining which 
changes took place as a result of the automerge and which were a result 
of the user.  This can be done implicitly (work out what the automerge 
would have done, compare to the actual changes), but without keeping an 
automerge version number, it's not possible to work this out any more 
should the automerge algorithm ever be changed/improved.

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