Re: [Monotone-devel] Kicking around ideas

[Thomas Keller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Leake schrieb:
> Thomas Keller <address@hidden> writes:
>> Consider the following workspace:
>>
>> $ mtn mkdir source
>> $ touch source/a
>> $ mtn add source/a && mtn ci
>> $ mtn mv source target
>>
>> The current inventory implementation allows a path restriction only on
>> nodes which actually exist, so while
>>
>> $ mtn au inventory target
>>
>> works,
>>
>> $ mtn au inventory source
>>
>> does not. 
> 
> It reports that "source" is not in the filesystem, so you can't
> restrict the filesystem path to it. That seems reasonable.

Well, why exactly shouldn't one be able to restrict on such a node?
After all, inventory outputs the old and new roster contents merged
together, and after _that_ the current file system is taken into account
and mapped onto the particular nodes (and inventory is expanded by
unknown and ignored nodes both rosters do not know anything about).

If a node A and its subnodes are dropped, does it mean inventory should
not be able to list all those dropped nodes if it is restricted on A? At
least I would like to get this information...

>> 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.
> 
> Why would this be the right thing to do?
> 
> What is the user trying to accomplish?
> 
> If the user executed "mtn mv source target", but then forgot they did
> that, the best solution is to do "mtn automate inventory" without a
> restriction, to see the state of the entire tree.

The "user" is in this case my GUI which does lazy expansion of the
inventory tree. Imagine a situation where a file system watcher notices
"source has been removed from disk". This action would trigger a re-read
of the inventory, restricted to the "source" path. Currently, this would
fail, because "source" is missing and therefor cannot be used in the
restriction. However, re-reading the whole inventory

a) would take too long for huge workspaces, and
b) would make me having to rebuild the whole inventory tree in the GUI
and thus loose the user's focus, which could be still in some completly
different context.

So no, I need exact output for a restriction on any known node.

I implemented include/exclude expansion in
6a5cce62aa4984e3c273949e5c9fa2ad57def517, I'll however experiment a bit
more with optionally removing the output of not explicitely named nodes
I introduced in 21df26c11c64ceb3386c132c71bb9434c5f41436, since the
output of those "opposite" nodes may not only confuse implementors, but
the fix from 3a9c12f498b2446ff8b570ffc254367287203189 also almost
doubles the time inventory takes to execute on renamed nodes:

$ # in the monotone source tree
$ mtn mv tests tests_new

# mtn 0.38:
$ time ./mtn au inventory tests_new >/dev/null
0,28s user 0,08s system 99% cpu 0,358 total

# mtn from 3a9c12f498b2446ff8b570ffc254367287203189:
$ time ./mtn au inventory tests_new >/dev/null
0,50s user 0,07s system 97% cpu 0,586 total

# mtn from 6a5cce62aa4984e3c273949e5c9fa2ad57def517:
$ time ./mtn au inventory tests_new >/dev/null
0,50s user 0,08s system 98% cpu 0,591 total

Thomas.

- --
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHld2Kaf7NlBYNEJIRAtHRAJ0dfpNTJPD9j5IqoBZe7rNTR0rzYQCcCwjv
hUx/J1w7sbvDygs0tSmOVf0=
=Khrt
-----END PGP SIGNATURE-----