Tue 18 Jul 2006 09:06:29 PM UTC, comment #2:
Now this is interesting: Having literally scanned the HTML docs for the automate command "attributes" I couldn't find anything there, but `mtn automate`clearly lists it as supported command. I have to admit that I normally only look at the docs to find out if a certain feature is supported or not, and not the binary's help output. So, after all, this is at least a documentation bug =)
Looking at the sources in automate.cc told me that it was added back in 1.0 and can do two things:
a) called without a parameter it simply lists all files with attributes settings
b) called with a FILE parameter it lists all attributes for that particular file (or exits with no output if the file has no parameters)
Through my tests I could verify that
a) it works if the file is missing (has been removed from workspace but not from mtn)
b) it also lists attribute additions which are not yet committed (though those can't be distinguished from those which are already committed), but doesn't list those which are dropped but not yet committed
c) it doesn't output the attribute values
After all, yes, I'm for updating automate attributes (beside that it should finally get documented), and I still wonder whats the use case of getting a manifest or a revision via automate interface while this output is not 100% accurate in terms of error handling (I mean we don't live in a perfect world, why should both commands imply that in "their" universe).
|
Mon 10 Jul 2006 02:49:58 PM UTC, original submission:
get_manifest_of can be used in conjunction with get_revision to query attributes, which simply exist (manifest) or have been added/dropped (get_revision amongst other things).
Now, when a file is missing from the workspace of the user, because it has been deleted but not yet mtn drop'ed, get_manifest_of (and get_revision likewise) fail with
$ echo "l15:get_manifest_ofe^c" | LC_ALL=c mtn automate stdio
mtn: warning: missing build.sh
0:2:l:316:misuse: 1 missing files; use 'mtn ls missing' to view
misuse: to restore consistency, on each missing file run either
misuse: 'mtn drop FILE' to remove it permanently, or
misuse: 'mtn revert FILE' to restore it
misuse: or to handle all at once, simply 'monotone drop --missing'
(Note, that the mtn: warning is not part of the stdio output, but is echoed to stderr, but this is another thing)
This might be correct behaviour on the first look, but it isn't. automate inventory lists missing files as missing and does not bail out, giving my UI a chance to revert the item or drop it if the UI acknowledges it.
While the user can decide when he does this action (the item is still just displayed as "missing" in the meantime), he can't use other functionality, like listing attributes of existing files, because, yep, get_manifest_of fails completly (and not only for the one single item which is actually missing). So the user is stuck until he acts on the missing item.
Now, my UI might get the notice "there are one or more missing items" (which it has to painfully parse from the error output), but it can't tell the user what items are actually missing since this is outputted to STDERR and not STDOUT of automate stdio (see above). Also, there is no "ls missing" command available for stdio, so I can't get the info through this interface at all.
A minor fix would here to include the warning into the actual stdio output, but this doesn't fix the other problems, mainly that the error string hard to parse, not basic_io or anything, and that it shouldn't fail at all - since the attributes for the file should still be recorded in the base revision even if the file is missing, the same goes for the file id where the last committed file ID could be used for existing files and an empty file id could be outputted for just added, but missing files.
Even better would be (that would help me not getting a bunch of nightmares) to allow get_manifest_of to be optionally be called with a pathname, so it only outputs the attributes and file ID of the single item (then it can fail for missing files, since the rest of the UI isn't corrupted). And even better would be to add to this format the possibility to show added/dropped attributes so one hasn't to take care of get_revision as well just to get the information "show me all added, dropped and still existing attributes of a file".
|