Re: [Monotone-devel] Kicking around ideas

[Derek Scherger]

Thomas Keller wrote:
> does not. The latter was "fixed" by me already in
> 3a9c12f498b2446ff8b570ffc254367287203189 simply by adding another
> argument to the path_restriction ctor which optionally skips the path
> validity checks, but I think this is merely a hack.

Yeah, with this I can presumably say 'mtn automate inventory blarf' and 
it won't complain or produce any output if I've mis-spelled the name I'm 
actually interested in. That was the original rationale when these 
checks went in anyway. I can't remember who, but at least one user 
complained that it had not produced any output when they had restricted 
to a bogus name.

> Anyways, even with this fix, there are some doh's:
>
> * mtn au inventory source correctly outputs the source/ and source/a
> nodes, but lists target/ and target/a as missing with fs_type set to
> "none". This is clearly wrong (both exist) and can be checked by
> restricting mtn au inventory to target.
>
> * On the other hand, an mtn au inventory target now lists target/ and
> target/a correctly, but fails to notice f.e. if source/ is an existing,
> unknown directory.
>
> The reason why both cases fail is because the node_restriction includes
> two paths for each node, while the path_restriction only one of the
> path, so the tree walker later misses to get the fs state of the
> "additional" paths.

I don't completely follow this. I would expect the tree walker to notice 
the target nodes because they do exist on the filesystem. I would expect 
it to not notice the source nodes because they don't exist on the 
filesystem.

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

This has come up a few times but I would be surprised if people didn't 
complain loudly if they had to list both names. I could be wrong though. ;)

> Thinking on our side, there are two possible ways to fix it:
>
> a) add all paths which are included by node_restriction as additional
> include paths for the path_restriction - this is expanding "source" or
> "target" to "source target" through the "backdoor".

This doesn't sound so bad actually. At least the set of paths that would 
be considered valid would be the same for both the path and node 
restrictions.

> I'm tending to implement b), what about you?

Another option might be to require that names be listed with some form 
of OLD/NEW revision specifier so that listing either side of a rename 
can be done unambiguously.

i.e.
        mtn auto inventory address@hidden address@hidden

This might solve some problems but it also wouldn't surprise me if it 
created some new ones. ;)

As I understand it, bzr has good support for renames. I wonder what they 
do in these cases, or if they support things like "rename a b + rename b 
a" or "rename a foo + add a" or "drop b + rename a b".

Cheers,
Derek