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

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Stephen Leake schrieb:
>
>>> $ mtn rename foo tmp
>>> $ mtn rename bar foo
>>> $ mtn rename tmp bar
>> So if the user had done 'automate inventory' between each of these
>> steps, it would have been clearer.
>> Let's see; 'path' gives the name in the current workspace filesystem.
>> 'new_path' gives the name in the current (uncommitted) revision
>> manifest. 'old_path' gives the name in the committed revision
>> manifest.
>
> Thats not totally true. 'path' can also point to an old or a new path.
> F.e. if an item is dropped, you get the following output:
>
>      path "dropped_file"
> old_type "file"
>   fs_type "none"
>    status "dropped"
>
> The output for added items is similar:
>
>      path "added_file"
> new_type "file"
>   fs_type "file"
>    status "added" "known"
>
> 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.

Although I'm not sure what that means for missing and dropped files;
they don't exist in the filesystem.

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.

You've also confused 'stanza' with 'line'; I think 'stanza' means
'group of lines'? I need to write that up ...

> Now the interesting question here is actually what 'path' is if the
> item was both, rename source and rename target. Can't answer this
> properly right now.

If 'fs_path' is simply the current name in the filesystem, this is
resolved.

> As a sidenote, I thought about having two rename states,
> "rename_source" and "rename_target", but then decided against this
> because what the item actually is, is implicitely told by old_path
> and new_path (just like before through the node ids). But maybe its
> not that a bad idea to make this more explicit, I dunno.

In general, I think it's better to be explicit, as long as it doesn't
get overly verbose.

-- 
-- Stephe