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

[Thomas Keller]

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.

> 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.

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

Sorry for that, I meant line. I'm not a native english speaker, so 
sometimes things like this happen.

> > 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.

Ok, I will change this.

Thomas.

--
ICQ: 85945241 | SIP: 1-747-027-0392 | http://www.thomaskeller.biz
> Guitone, a frontend for monotone: http://guitone.thomaskeller.biz
> Music lyrics and more: http://musicmademe.com