monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: graydon hoare
Subject: Re: [Monotone-devel] long RFC: "contexts"
Date: Fri, 28 May 2004 11:54:26 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040208)

Jon Bright wrote:

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

that all sounds good, and I can accept the logic of keeping author/date/comment/log as certs (possibly bundled), though I'm not *certain* it's better or worse. however:

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

this change (and removing the edge parent's manifest sha1) I think I object to. the reason for preserving the pre-state content identifiers is that you can synthesize the manifest and file deltas without reconstructing and analyzing the pre-state manifest. that's an efficiency argument, but imo an important one (especially during networking), and I don't think it introduces any variable noise. i.e. I think the "extra" explicit information of file and manifest pre-states is identical to the synthetic information one would get by analyzing predecessor changes and manifests, in all cases, so the object is not any more semantically "minimal" without it, just takes fewer bytes. I'd argue for the presence of those extra bytes.

otherwise I think we're converging on a proposal. shall we discuss concrete syntax next? there are a dozen conflicting pressures there :)

-graydon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]