monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] basic_io inventory


From: Stephen Leake
Subject: Re: [Monotone-devel] basic_io inventory
Date: Tue, 24 Apr 2007 20:21:25 -0400
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt)

Daniel Carosone <address@hidden> writes:

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

What should I do first?

I've got the monotone.basic_io.inventory branch compiled (on Win32
with MinGW).

I've looked thru the tests directory, and generally understand what is
going on.

The automate_inventory test is still expecting the old format; I guess
editing that test to work with new format would be one task.

There are probably other tests that should be added.

There is also the issue of how to deliver the results. I can post
patches here, but it would be better if I had publicly accessible
branch somewhere. Is there a public monotone server for that?

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

It would be interesting to measure.

Doing 'mtn automate inventory' on the monotone workspace takes 36
seconds on my machine; that includes printing to stdout. 

In any case, saving the parsing on the Emacs side is well worth it.
What would be the approach to adding such an option?

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

Ok.

'mtn help automate' does not show a "[PATH]..." parameter.

automate.cc has:

// Name: inventory
// Arguments: none
// Added in: 1.0

But later:

AUTOMATE(inventory, "[PATH]...", options::opts::none)

and 'mtn automate inventory tests' shows just files in the 'tests'
directory.

I guess this is one of the "documentation" things that needs to be fixed.

The help system is being reworked on another branch; we should
probably wait until that is merged to work on the help part of this.

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

Just showing the true rename result seems reasonable. I take
'inventory path' to mean 'tell me the current state of all files in
path'; that includes knowing that something was renamed elsewhere.
Users of 'automate inventory path' will have to be prepared to cope
with that.

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

That explains why the help and comments don't mention PATH.

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

That is certainly a choice. There is little difference to an Emacs
function between "automate inventory -no_unchanged" and "automate
inventory_no_unchanged"; I agree building the automate stdio string in
the second case is slightly easier, but we'll have a function for
that, anyway.

So I think it's more a question of which way is better for organizing
the documentation, and the C++ code.

--
-- Stephe




reply via email to

[Prev in Thread] Current Thread [Next in Thread]