[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Kicking around ideas
From: |
Derek Scherger |
Subject: |
Re: [Monotone-devel] Kicking around ideas |
Date: |
Mon, 21 Jan 2008 20:25:55 -0700 |
User-agent: |
Thunderbird 2.0.0.9 (X11/20071116) |
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
Re: [Monotone-devel] Kicking around ideas, Stephen Leake, 2008/01/22