Re: [Monotone-devel] basic_io inventory (was xmtn: Emacs integration via DVC)

[Derek Scherger]

Thomas Keller wrote:
> The new format is almost set in stone, whats basically missing are
> tests, documentation and a code cleanup.

I wouldn't go so far as to say "set in stone" just yet. I can't remember
exactly what might change but IIRC there are some small things that
could still be improved.

The amount of interest is encouraging though, and considering that
apparently everyone who uses inventory has experienced the problems with
the old format and wants to see it fixed maybe we should actually do
something about it. ;)

> Wrt the new format, the following open questions remain:
> 
> a) should there be a more explicit rename marker in the new format than
> the rather implicit node ids? I think, yes, because for the
> path-/depth-restricted output we can't tell the exact state of the item
> (is it only dropped, or actually renamed?)

I don't think this is correct. Listing either old or new name of a
renamed path will include the *node* in a restriction and including the
node will list both old and new names in the resulting inventory output.
I also don't think it would be a terrible idea to list a bunch of path
status flags like added/dropped/renamed. However, note that it's
possible to see more than one of these, since a path can describe a node
that has been dropped or renamed out and also another node that was
subsequently added or renamed in, etc.

> b) Since we already have those data in place: I'd vote for including the
> old and new fileid in the stanzas (where applicable)... this saves
> additional calls to automate identify or automate get_manifest_of for
> the interface programmer.

you're talking about sha1 file_ids eh? (i.e. not the node_id's that are
already listed)? it would be trivial to list them and I don't see real
down-side to doing that. if you aren't interested in them then ignore them.

Cheers,
Derek