Re: [Monotone-devel] 3 proposed changes to manifest/changeset format

[Nathaniel Smith]

On Wed, May 11, 2005 at 10:26:33AM +0800, Matt Johnston wrote:
> On Tue, May 10, 2005 at 03:26:40AM -0700, Nathaniel Smith wrote:
> > Some smaller changes are in the offing, though:
> > 
> > - First-class directory support 
> 
> If it'll fix dir dropping etc, sounds sane. Would this have
> consequences for making the root directory renamable? I'd
> like to seen renamable root directories eventually getting
> supported, as it seems to provide a convenient way to bring
> third party branches into a project (ie "/" of the
> hypothetical org.sqlite.sqlite branch gets renamed to
> "sqlite/" when propagated to the net.venge.monotone branch). 

I'm interested in this feature too.  This particular change doesn't
have any direct effect, except that we might want to come up with some
name for the root directory.  (Ugh.)  Or I guess we could later add a
"rename_root" changeset op.  (Ugh.)

The sort of general goal is to make the revision/changeset/manifest
format be as close a match as possible to the actual underlying
domain; they should exactly record what really happened, and not
record anything else.  (For instance, unique persistent file
identifiers do not actually exist in the model domain; they're
something additional that a VCS might add to make its job easier.  So,
they shouldn't be in this format.)  The meta-goal is to make this
data neutral between different sorts of internal representations and
algorithms that might want to run over it, so we can adjust those
parts as needed.

> > - Patches on delete_file: Currently, there's an assymmetry in the
> > change_set format -- add_file "foo" is accompanied by patch "foo" from
> > [] to [<initial hash>].  delete_file "foo", on the other hand, is not
> > accompanied by a patch "foo" from [<final hash>] to [].  The reason
> > for this is that such a hash would be redundant, but I think it's a
> > decision worth revisiting.
> 
> My gut feeling is that having the explicit patch to [] is
> likely to increase the chances of triggering invariants in
> edge/untested cases for change_set.cc, which is a good thing.

Good point.

> > - Attributes in manifests: this is a speculative idea, raised for
> > discussion -- if we use basic_io for manifests, it becomes pretty
> > straightforward to include file attributes (like .mt-attrs currently
> > stores) directly into the manifest, if we want to.  Presumably this
> > would also involve adding "set_attr" and "delete_attr" type operations
> > to changesets.
> 
> One issue here is that without changes to the revision
> format, it'd be possible for a revision to have no changeset
> information yet differing old_ and new_ manifests, when only
> the attributes are altered?

Yeah, right now manifests are technically redundant, since they are
fully reconstructible from the changeset history.  This seems like an
important property to preserve.  (Why have manifests at all, then?
Because they provide end-to-end tree state integrity checking -- there
might be bugs in the change set logic, but so long as the hash of the
manifest of my checkout matches the hash of the manifest of your
checkin, we can be certain we have the same tree.  They're probably
handy for things like partial pulls, too, where one wouldn't have
access to full history...)

-- Nathaniel

-- 
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould