Re: [Monotone-devel] basic_io inventory

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Daniel Carosone schrieb:
>> On Sun, Apr 22, 2007 at 07:03:36PM +0200, Christian Ohler wrote:
>>> The reason why xmtn doesn't have a proper implementation of
>>> dvc-status yet is that xmtn doesn't have a parser for mtn automate
>>> inventory; I was hoping to be able to use a basic_io variant of
>>> automate inventory instead (since xmtn has a basic_io parser).  The
>>> code for a basic_io variant of automate inventory exists on a
>>> branch but has unfortunately never been finished.
>> That's a perfectly reasonable stance.  What's left to be done to
>> finish the inventory-as-basic_io stuff?  ISTR it was basically done,
>> and essentially pending some kind of consensus or mandate that folks
>> were happy with the new format, right?
>
> The new format is almost set in stone, whats basically missing are
> tests, documentation and a code cleanup.

I can help with the tests and documentation. I'm not familiar enough
yet with monotone code to do cleanup on it.

For me, the primary use case for Emacs DVC monotone is to get a list
of files that need attention; most of the time, that's a very small
subset of the files in the workspace.

So I'd like to add an option to not output any info for files that are
currently up-to-date. That would save significant time both in running
'mtn automate inventory' and in parsing the output in Emacs.

> Wrt the new format, the following open questions remain:
>
> a) should there be a more explicit rename marker in the new format
> than the rather implicit node ids? I think, yes, because for the
> path-/depth-restricted output we can't tell the exact state of the
> item (is it only dropped, or actually renamed?)

I don't see how to specify 'path-/depth-restricted output'; 'mtn help
automate inventory' does not show any inventory-specific options, and
I don't see any in the code either. But I could easily be missing
something.

> b) Since we already have those data in place: I'd vote for including
> the old and new fileid in the stanzas (where applicable)... this saves
> additional calls to automate identify or automate get_manifest_of for
> the interface programmer.

I don't see many commands that take a fileid; the commands most
interesting from an Emacs interface point of view just need the file
path. So perhaps fileid output should be requested via an option, to
save parsing time in the typical case. 

-- 
-- Stephe