Thomas Keller <[EMAIL PROTECTED]> writes: > Hi all! > > I just pushed 0472d09c092424674bae4acfced5c51dc51de408 which drops the > file ids and rather displays old and new path of an item together with > a status string. Example output: > > <snip>
This looks excellent. I ran Christian's timing test on this version, on Windows MinGW; 9 sec/iteration (same as the previous version). Commenting out all output code in 'automate inventory' reduces that to 3.8 sec/iteration. > However, there is a bug in the current format I'm unsure how to fix: > if inventory is restricted to newdir/, newdir/foooo's state is > outputted wrongly as "added" as well as there is no "foooo" node: > > $ mtn automate inventory newdir > path "newdir" > old_type "directory" > new_type "directory" > fs_type "directory" > status "known" > > path "newdir/foooo" > new_type "file" > fs_type "file" > status "added" "known" I'm not sure what the problem is here. Are you saying that 'newdir' is in fact a "new directory", and all files in it should be listed as "unknown"? > On the other hand, depth-restricting the root directory produces > similar false results by omitting newdir/foooo: > > $ mtn automate inventory --depth 0 > path "" > old_type "directory" > new_type "directory" > fs_type "none" > status "missing" > > path "blubba" > old_type "file" > new_type "file" > fs_type "file" > status "known" > > path "foooo" > old_type "file" > fs_type "none" > status "dropped" > > path "newdir" > old_type "directory" > new_type "directory" > fs_type "directory" > status "known" > > All this is actually not a bug in the recently committed code, but > rather a bug in the restrictions code. Ok. We need to add tests for these cases. > Apart from that, the following open bugs/things to implement for > inventory remain: > > a) The "" (root) node is outputted as fs_type "none" and status > "missing", this is clearly not true, but on the other hand the root > node is a special node, so we might find some special workaround here > to either omit it or output it differently? (I.e. the only thing that > can actually happen to a workspace' root node is that it is renamed by > pivot_root'ing or attributes are attached to it; all other things just > don't make sense for it, unless I forgot something) I forgot about pivot_root. I guess 'automate inventory' does need to be able to report that event. The root node certainly should be handled specially in the code. > b) Currently, my new code seems to produce a bit irritating output > when it comes to cyclic renames: > > path "blubba" > old_type "file" > new_path "foooo" > new_type "file" > old_path "foooo" > fs_type "file" > status "renamed" "known" > > path "foooo" > old_type "file" > new_path "blubba" > new_type "file" > old_path "blubba" > fs_type "file" > status "renamed" "known" > > > Here, blubba and foooo are swapped, but you can't easily determine > that from scanning over it, because both paths, old_path and new_path, > are equal for each item, but of course point to the correct nodes for > the respective roster. I don't understand why the old_path for "blubba" is not "fooo", and vice-versa. That is certainly what is output for non-cyclic renames. This also needs a test case. What is the sequence of commands for this? > c) Since this has been requested alot recently, we need to implement > some option to hide unknown and/or ignored files from inventory's > output to speed up the whole thing for people who're calling this very > often on very big workspaces. Actually, I'm looking for "no-ignored" and "no-unchanged". "no-unknown" might also be desirable in some situations. Looking thru the code briefly, it seems options are declared in options_list.hh. We could use the existing "brief" to mean "no-ignored" and "no-unchanged". We also need: d) Updated tests/automate_inventory I have not made much progress on this. e) updated monotone.texi -- -- Stephe _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel