bugmonotone - Bugs: bug #16939, RFC for new automate inventory

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #16939: RFC for new automate inventory

Submitted by:  Thomas Keller <tommyd>
Submitted on:  Mon 26 Jun 2006 12:56:22 AM UTC  
 
Category: command line UISeverity: 3 - Normal
Item Group: feature requestStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed
mtn version --full: 

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?

Thomas Keller <tommyd>
Project Administrator

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by tbrownaw (Updated the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 25 Nov 2007 04:00:52 PM UTCtbrownawStatusNone=>Fixed
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1