Re: [Monotone-devel] Changes in nvm.basic_io.inventory

[Stephen Leake]

Derek Scherger <address@hidden> writes:

> One thought that along these lines is that perhaps we should change the
> entire focus from paths to nodes:
>
> node "1234"
> old_name "foo"
> new_name "bar"
> old_content [1234...]
> new_content [5678...]
> status "renamed" "patched"
>
> node "5678"
> old_name ""
> new_name "foobar"
> old_content []
> new_content [1234]
> status "added"
>
> node "9876"
> old_name "foobar"
> new_name ""
> old_content [1234]
> new_content []
> status "dropped"
>
> node "1313"
> name "asdf"
> status "unknown"
>
> etc.

This is similar to my suggestion. Note that the node id is not
actually useful for anything, so there's not much point in outputting
it. In this case, it just serves as a reliable first line in the
stanza; 'status' could be first instead.

Hmm. It just occurred to me that a reliable _last_ line is just as
good as a reliable _first_ line, as far as dividing lines into stanzas
goes. Although it would be good to standardize whether the first or
last line is reliable for _all_ basic_io output, so stanza-based
parsers can be standardized.

Emacs DVC doesn't use the content info (at least for now); what use do
you forsee for it?

> For "nodes" that don't exist in either roster the id's would presumably
> be temporaries (see temp_node_id_source).

Right. Which may be a problem for the unit tests, since the temporary
node ids may not be repeatable across all hosts (for example, 32 bit
vs 64 bit may be a problem).

> This clearly isn't fully thought out but seems like it might be worth
> considering. I'm not sure how we would want to represent the
> filesystem's name for unknown/ignored "nodes" 

The filesystem path for these is clear (they are existing files);
what's not clear is the node id (it's a temporary).

The only piece of information that is well-defined for _all_ nodes is
the status.

> Perhaps instead of old_name and new_name lines we have lines like
>
> added "name"
> dropped "name"
> renamed "old_name" "new_name"
>
> and for nodes that have not had name changes we simply list
>
> name "name"
>
> then the corresponding status line might contain "known", "unknown",
> "ignored", "missing" etc.

In this case, the tool has to read the status line first, in order to
know what the other lines mean, or what other lines to expect in the
stanza. 

On the other hand, if the tool reads the whole stanza, and then
processes it, the order of lines doesn't actually matter.

> Yet another option might be to always list both old_name and new_name
> lines and just let them be the same thing in some cases. Note that in
> the case of a drop + add on the same name we would have two different
> node ids:
>
> node "1234"
> old_name "foo"
> new_name ""
> status "dropped"
>
> node "5678"
> old_name ""
> new_name "foo"
> status "added"
>
> Thoughts?

These are interesting suggestions. 

I don't think we should change the output so drastically without a
good reason; a lot of work has gone into the current format. I'm not
clear these formats are significantly better than your first one
above. By "better" I mean "easier for a tool to parse, less
ambiguous".

To resolve these issues, I think it would help to have more examples
of tools that will use the 'automate inventory' interface. I'm
focussed on Emacs DVC; what other tools plan to use this?

-- 
-- Stephe