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

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Yes, node_ids don't mean anything, but they serve as unique
> _identification_ for the upcoming stanza. The status is certainly not
> unique and therefor does not serve this purpose at all.

Ok. But when would a unique id of a stanza be useful?

>> 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?
>
> In general, I'm ok with _any_ format, as long as this cares about all
> corner-cases and gives me all the info I need. Sure, we could discuss
> the current or any other format to death within the next days/weeks,
> but this doesn't help anybody. I personally want to get the format out
> ASAP, and if real-life usage of the format reveals any flaws, then let
> us change that if _that_ happens.

Right. The only reason I'm talking about changing the format at all is
because you have posted some "corner cases" that are currently broken,
and I believe this change would fix those.

I'll work on adding those cases to tests/automate_inventory.

> We certainly have to rethink the format at least one more time in
> the future if multi-parented workspaces are fully thought out, so
> whatever we're developing here isn't set in stone forever anyways.
>
> The tool for which I need inventory is guitone [0]. For its main use
> case, a konqueror/explorer/whatever-alike filemanager view, I need
> inventory output not only tracked, but also untracked paths. So not
> only actions like commit or revert are interesting for me, but also
> actions like add, drop, ignore, unignore, etc. And for the latter ones
> f.e. I need to know which files in the current workspace are actually
> ignored and the only way to get this info over automate is inventory.

Ok.

> Fileids would be useful to determine renames which only happened in
> the filesystem (a "Quickie" task in the mtn wiki states a mtn rename
> --guess operation which is not yet implemented, but guitone will
> have this in 0.7), 

Ah! That's a good idea. 

> and any sort of state output is useful for view filtering and visual
> item separation (guitone places overlays over path icons depending
> on their state).

I'm not clear what you mean by "state" here. I guess that's "status"?

-- 
-- Stephe