Re: [Monotone-devel] Kicking around ideas

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> $ mtn mkdir source
> $ touch source/a
> $ mtn add source/a && mtn ci
> $ mtn mv source target

This test case is missing in tests/automate_inventory_restricted.

I've added it, both with and without "--bookkeep-only", with the
current output as the expected, so it passes.

> $ ls -la
> insgesamt 16
> drwxr-xr-x  5 tkeller users   43 21. Jan 18:13 .
> drwxr-xr-x 22 tkeller users 4096 21. Jan 18:20 ..
> drwxr-xr-x  2 tkeller users   58 22. Jan 09:38 _MTN
> drwxr-xr-x  2 tkeller users    6 21. Jan 18:13 source
> drwxr-xr-x  2 tkeller users   14 18. Jan 17:34 target

Hmm. To have "source" still present in the filesystem, you need
'--bookkeep-only' in the 'mtn mv' above. But then "target" would not
be there.

So I don't understand what this use case actually is. Perhaps you
could update the tests/automate_inventory_restricted test to show the
issue.

We've agreed that using '--bookkeep-only' makes the automate inventory
output confusing.

In my experience, executing "mv" in the filesystem but _not_ in mtn is
the typical workflow. Then automate inventory reminds you to do "mtn mv".

> $ mtn au inventory target
>     path "source"
> old_type "directory"
> new_path "target"
>  fs_type "none"
>   status "rename_source"
>
>     path "source/a"
> old_type "file"
> new_path "target/a"
>  fs_type "none"
>   status "rename_source"
>
>     path "target"
> new_type "directory"
> old_path "source"
>  fs_type "directory"
>   status "rename_target" "known"
>
>     path "target/a"
> new_type "file"
> old_path "source/a"
>  fs_type "file"
>   status "rename_target" "known"
>
> When I restrict on "target" like above, "source" is not part of the
> include paths and therefor gets the wrong fs_type (none instead of
> directory) and also misses one status (unknown).

In one sense this is correct; "source" is "fs_type none" because it is
not in the file system specified by the restriction. On the other
hand, it is not "unknown", because mtn does know about it.

Why is the user specifying a restriction in this case? And why are
they using --bookkeep-only? Knowning that would help resolve what the
"right" answer is here.

> The same happens the other way around: If I restrict on "source",
> "target" and "target/a" are not scanned, thus listed as missing:

And that does make sense, if we treat "the filesystem" as the one
specified by the restriction.

>>> An obvious way to "fix" this problem on the user side is to include both
>>> paths right from the start in the restriction, i.e. "mtn au inventory
>>> source target", but then the user has to know _beforehand_ that one of
>>> the nodes he's restricting is part of a rename. If he doesn't know,
>>> he'll simply get wrong output like the above.

Or run inventory with no restriction.

--
-- Stephe