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

[Thomas Keller]

Stephen Leake schrieb:
> > 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.

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.

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

The content info could be used to determine bookkeep-only renames which 
we discussed in a previous email. Also, there is automate get_file which 
takes a (known) content_id, so they might be useful under some 
circumstances.

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

We could just try it out and implement it in some branch and later 
decide what format is actually better.

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

Thomas.

[0] some screens: http://guitone.thomaskeller.biz/g/screens

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