Mon 26 Jun 2006 12:56:22 AM UTC, original submission:
The current automate inventory implementation lacks of certain features and is buggy (see #15748, #15981 and #16150). The main problems are
a) Incorrect display of dropped directories (they're missing the trailing slash, thus they can't be distinguished from normal files anymore)
b) If a file is dropped and an equally named directory is added or vice versa there is no way to specify that the former/latter object was a directory (since the path only reflects the post state)
c) Attribute changes are not displayed
d) There is no way to specify a certain subdirectory on which automate inventory should act or even to filter certain things out
Now, I guess for a), c) and d) it is possible to implement bugfixes / additions in the current model, while it will probably be hard to fix b) with the current format. Thats why I request an improved format for the automation interface based on basic_io and similar to the way get_revision and get_manifest_of are outputted.
Actually both commands output parts of what is needed for a fully functional inventory output, but I'd like to see it slightly different:
$ mtn automate inventory [--root /path/to/subdir] [--only-status [added|...]]
format_version "2"
[file|dir] <nodeName>
attSet <attrName> <attrValue>
attrDrop <attrName>
oldType [dir|file]
renameSource <newName>
renameTarget <oldName>
status [added|dropped|patched|ignored|unknown|missing|renamesource|renametarget|attrset|attrdrop]
oldFileId <ID>
newFileId <ID>
...
Obviously not every line makes sense for every entry. E.g. if a file is unknown or ignored, it won't have oldFileId nor newFileId. (Note: what is oldFiledId set to if a dir is dropped (which has no file id) and a file is added (which has one)? Is the oldFileId field omitted?)
The renameSource/Target fields would contain the full paths of the latter items since the current integer mapping won't fit the use case that only a subtree should be outputted and the renamed source/target resides outside of this subtree. Giving a full path can inform the GUI "hey, update this subtree as well!".
The status field could contain several states (comma-separated f.e.). Two new status fields would be introduced which reflect changes to attributes. Notice that renamesource and renametarget as well as attrset and attrdrop may be mentioned here obviously they could be determined by single renameSource, attDrop aso. entries. The reason is just that a GUI might simply display that something has changed but would ignore the information at some point what exactly has changed.
The root item ("") wouldn't be omitted in this model as well and could receive its own entry i.e. if there are attribute changes.
So what do you think? Anyone up to implement that?
|