monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Kicking around ideas


From: Thomas Keller
Subject: [Monotone-devel] Kicking around ideas
Date: Mon, 21 Jan 2008 17:31:37 +0100
User-agent: Thunderbird 2.0.0.6 (X11/20070801)

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


Hi all!

I'm currently working on automate inventory (again) to fix certain
issues which came up after I tried a test implementation for guitone.
This is all about renames and the restricted output on those nodes.

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

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.

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.

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

b) find a way to somehow remove the inventory output of all nodes to
which the user has not explicitely restricted to. I know there was a lot
of struggle to get this output in there, but lately I think this
"feature" makes people more perplex than it is actually useful.
  If you restrict to "source" today, you get the tree below "source" and
below "target". A parser which is only expecting something what was fed
into inventory might likely get confused (and because of lexical sorting
it is not even guaranteed that the output will start with the nodes to
which the output was restricted).
  On the other hand, the current output contains everything for the
parser / tool developer to know "hey, this is a rename, to get the other
part of it, I just look at the output of 'mtn au inventory (new_path or
old_path of root node)'"


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

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

iD8DBQFHlMjpaf7NlBYNEJIRAiLbAJ4jSFMSP7Xa4a0pqL9vYp+s21T3fQCfYDHw
TIEHZ05UVo1PyJem5+UKYQQ=
=BykS
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]