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

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Stephen Leake schrieb:
>>> So, its actually this way: If a file is dropped (status "dropped"),
>>> 'path' is the path in the old roster. If a file is added (status
>>> "added"), 'path' is the path in the new roster. If a file is renamed,
>>> 'path' is either an old or a new path, depending if there is a
>>> 'new_path' stanza (then its an old path) or an 'old_path' stanza (then
>>> its a new path).
>> I find this confusing.
>> Perhaps it would be less confusing if we change it to work the way I
>> stated it above; then the output of 'automate inventory' is more
>> directly related to the state of the filesystem and manifests.
>
> I think the 'path' usage is quite understandable. It never brought up
> any complaints even for the old, line-based format, where the path had
> the same "multi-meaning". But we may want to work out old_path and
> new_path a bit, or, if it is altogether too confusing, leave it out
> and display node ids as it was implemented before.

The node ids were not less confusing; we are making progress!

>> Although I'm not sure what that means for missing and dropped files;
>> they don't exist in the filesystem.
>
> Thats why the output interweaves entries from the old and the new roster.
>
>> Perhaps 'path' should be absent if fs_type is 'none'. And perhaps 'path'
>> should be 'fs_path', to be consistent with 'old_path'.
>> Then the stanza should start with 'status', since there needs to be a
>> line that reliably starts a stanza; parsers should not rely on
>> whitespace.
>
> Personally, I don't like this idea. IMHO a stanza should always start
> with something that identifies the upcoming data, like a path, or at
> least a node id or something. The status string is not at all usable
> for that.

In general, I agree; the first line of a stanza should indicate what
will follow. In this case, I think the "status" line fills that role
better than "path", since "fs_path", "old_path" and "new_path" are
undefined when the current node is not in the corresponding source.

We could use "fs_type", "old_type", or "new_type" as the first line,
since those are always well defined. But "status" is more meaningful;
it defines what actions are available for the current node (commit,
revert, remove, display diff, declare a rename, etc).

We could also output the node_id. But that is not actually useful for
the external tool, so I don't think that's a good choice.

For nodes that appear in all three sources, the status line says "here
is a node that appears in all three sources":

  status "known"
 fs_type "file" 
 fs_path "unchanged" 

It is sufficient to just output 'fs_type' and 'fs_path', since the
status line indicates that the others are the same.

  status "known" "changed_content"
 fs_path "patched"
 fs_type "file"

(here I've merged the "changes" line into the "status" line; I think
that's a good idea)

For a node that only appears in the old manifest, the status line says
that:

  status "dropped"
old_path "dropped"
old_type "file"

For a node that appears in the new and old manifests, but not in the
filesystem:

  status "missing"
old_type "file"
old_path "missing"

For a node that appears only in the new manifest:

  status "added" "missing" 
new_type "file"
new_path "missing"

This is a fairly large change in the appearance of the output, but I
suspect it is _not_ a large change in the code (it should be simpler),
and it will resolve the ambiguous cases that have been presented so
far. And it will be simpler for a tool to interpret.

One way to look at this is as a change of focus, from "what do I know
about this file" to "what can I do with this node". 

Since monotone supports renaming, the notion "this file" is often
ill-defined. But "this node" is always well-defined, as are the
operations that can be performed on it.

Another point; this interface is for tools, not people. So if a user
likes combining one of "fs_path", "old_path" and "new_path" into a
display field "path" (as the current 'automate inventory' output
does), they can have the tool do that (and I suspect Emacs DVC will do
that). 'automate inventory' should present the information to the tool
in a way that is as simple and un-ambiguous as possible.

--
-- Stephe