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

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Hi all!
>
> I just pushed 0472d09c092424674bae4acfced5c51dc51de408 which drops the
> file ids and rather displays old and new path of an item together with
> a status string. Example output:
>
> <snip>

This looks excellent.

I ran Christian's timing test on this version, on Windows MinGW; 9
sec/iteration (same as the previous version). Commenting out all
output code in 'automate inventory' reduces that to 3.8 sec/iteration.

> However, there is a bug in the current format I'm unsure how to fix:
> if inventory is restricted to newdir/, newdir/foooo's state is
> outputted wrongly as "added" as well as there is no "foooo" node:
>
> $ mtn automate inventory newdir
>      path "newdir"
> old_type "directory"
> new_type "directory"
>   fs_type "directory"
>    status "known"
>
>      path "newdir/foooo"
> new_type "file"
>   fs_type "file"
>    status "added" "known"

I'm not sure what the problem is here. Are you saying that 'newdir' is
in fact a "new directory", and all files in it should be listed as
"unknown"?

> On the other hand, depth-restricting the root directory produces
> similar false results by omitting newdir/foooo:
>
> $ mtn automate inventory --depth 0
>      path ""
> old_type "directory"
> new_type "directory"
>   fs_type "none"
>    status "missing"
>
>      path "blubba"
> old_type "file"
> new_type "file"
>   fs_type "file"
>    status "known"
>
>      path "foooo"
> old_type "file"
>   fs_type "none"
>    status "dropped"
>
>      path "newdir"
> old_type "directory"
> new_type "directory"
>   fs_type "directory"
>    status "known"
>
> All this is actually not a bug in the recently committed code, but
> rather a bug in the restrictions code.

Ok. We need to add tests for these cases.

> Apart from that, the following open bugs/things to implement for
> inventory remain:
>
> a) The "" (root) node is outputted as fs_type "none" and status
> "missing", this is clearly not true, but on the other hand the root
> node is a special node, so we might find some special workaround here
> to either omit it or output it differently? (I.e. the only thing that
> can actually happen to a workspace' root node is that it is renamed by
> pivot_root'ing or attributes are attached to it; all other things just
> don't make sense for it, unless I forgot something)

I forgot about pivot_root. I guess 'automate inventory' does need to
be able to report that event.

The root node certainly should be handled specially in the code.

> b) Currently, my new code seems to produce a bit irritating output
> when it comes to cyclic renames:
>
>      path "blubba"
> old_type "file"
> new_path "foooo"
> new_type "file"
> old_path "foooo"
>   fs_type "file"
>    status "renamed" "known"
>
>      path "foooo"
> old_type "file"
> new_path "blubba"
> new_type "file"
> old_path "blubba"
>   fs_type "file"
>    status "renamed" "known"
>
>
> Here, blubba and foooo are swapped, but you can't easily determine
> that from scanning over it, because both paths, old_path and new_path,
> are equal for each item, but of course point to the correct nodes for
> the respective roster.

I don't understand why the old_path for "blubba" is not "fooo", and
vice-versa. That is certainly what is output for non-cyclic renames.

This also needs a test case. What is the sequence of commands for this?

> c) Since this has been requested alot recently, we need to implement
> some option to hide unknown and/or ignored files from inventory's
> output to speed up the whole thing for people who're calling this very
> often on very big workspaces.

Actually, I'm looking for "no-ignored" and "no-unchanged".

"no-unknown" might also be desirable in some situations.

Looking thru the code briefly, it seems options are declared in
options_list.hh.

We could use the existing "brief" to mean "no-ignored" and
"no-unchanged". 

We also need:

d) Updated tests/automate_inventory

I have not made much progress on this.

e) updated monotone.texi

-- 
-- Stephe