Re: [Monotone-devel] basic_io inventory

[Daniel Carosone]

On Tue, Apr 24, 2007 at 02:51:35AM -0400, Stephen Leake wrote:
> I can help with the tests and documentation. 

Excellent.

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

Really only the latter; we still need to examine the workspace to
determine the file is up to date so we could then not list it, and
that's by far the majority of the time.

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

"restrictions" are a general purpose option for many commands, so you
can request things like diff or commit for a restricted subset of
files in the workspace.  They're often shown as "[PATH]..." in help
(perhaps another thing to tidy up in that branch?).

The issue here is how to show the difference between a file that has
been renamed somewhere else outside the restriction, vs one that has
been dropped.  I don't have an immediate answer.

(I assume the new form takes restrictions, the current doesn't seem to).

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

From a UI point of view, I'm not sure options to automate commands
(especially via stdio) are all that appealing; if there's a strong
case for several different output forms, they c/should be separate
automate commands (with similar names, and as much shared
implementation as possible).

--
Dan.

pgp83hWUHCXGu.pgp
Description: PGP signature