Re: [Monotone-devel] automate inventory

[Timothy Brownawell]

On Sun, 2006-04-09 at 22:53 -0600, Derek Scherger wrote:
> I've been playing around with automate inventory a bit lately to try and
> make the implementation a bit more roster friendly and fix a couple of
> small-ish issues.
> 
> For reference the current format is (roughly):
> 
> column 1: pre-state
>       unchanged, dropped, renamed from
> column 2: post-state
>       unchanged, renamed to, added
> column 3: node-state
>       unchanged, patched, unknown, ignored, missing
> 
> followed by two numbers used to tie renames together
> followed by the path in question, ending with a '/' for directories
> 
> as a regex (with a ficticious :path: character class) this is something
> like:
> 
> [ DR][ RA][ PUIM] [0-9]+ [0-9]+ [:path:]+/?
> 
> Inventory is about listing the state of every path in the workspace and
> comparing that state with the revision the workspace is based on. The
> intention being to provide something suitable for building IDE
> integrations or other GUI's on top of, that tend to want to indicate
> paths that have changed, been added or deleted or renamed.
> 
> The issues I know about are:
> 
> 1. There is no indication of attribute changes. presumably something
> like an "A" would indicate that attributes for the specified path have
> changed in the same way that "P" indicates changes to the content of the
> specified path.
> 
> 2. The trailing '/' to indicate directories is somewhat broken. There
> are *three* possible sources of "type" associated with any path: the old
> roster, the new roster and the filesystem. For example a file may be
> dropped and a directory added in its place, or a file and a directory
> may be swapped, etc.
> 
> Do the pre/post add/drop/rename things still make sense or would simple 
> states (old node id, new node id) from which these actions can be 
> inferred be better? Rather than the pre/post "state" columns perhaps we 
> just list the old and new roster node ids that identify the path:
> 
> 0 123 added
> 456 0 dropped
> 111 0 renamed_from
> 0 111 renamed_to
> 
> Note that 0 would presumably mean that the path does not exist in the
> associated roster. Any node id that appears on different paths from both
> the old and new roster indicates a rename.

I like this idea, yes.

> In addition to this we still need:
> - something to indicate known/unknown/ignored/missing
> - something to indicate content changes
> - something to indicate attribute changes
> - something to indicate type in the rosters and on the filesystem
> 
> Currently the content change is mixed in with the
> unknown/ignored/missing flags but perhaps separating this out would be a
> good idea?
> 
> Content/attribute changes would presumably only be relevant for paths
> that appear in the new roster and on the filesystem. i.e. not possible
> for missing paths and not interesting for non-versioned paths. I'm not 
> even sure anything is in place for detecting attribute changes between 
> the new roster and the filesystem?

Attribute changes are between the old and new rosters.

> Also, we should probably add some sort of "confused" path state to the 
> known/unknown/ignored/missing things to handle paths that disagree on 
> file/directory type between the new roster and the filesystem.
> 
> So, any thoughts on all of this? 

Well, IIRC we're trying to use basic_io as our general data format. This
would be a lot more flexible than trying to keep the same
one-line-per-item style inventory uses now.

Maybe something like


           path "foo/bar.mp3"
        fs_type "file"
       old_type "dir"
       new_type "file"
         old_id "123"
         new_id "456"
        patched "true"
  attrs_changed "id3:title"
  attrs_cleared "mtn:exec"
    attrs_added "mtn:manual-merge" "id3:track"

    path "core"
 fs_type "file"
old_type "absent"
new_type "absent"


*_type can be "file", "dir", or "absent", and *_id is only present if
the matching *_type is not "absent".

patched and attrs_* refer to the item with id new_id, and are only
present if the file was patched, or the matching something happened to
at least one attr. (and are only present if they actually mean
something, so new_type can't be "absent". and for patched, neither can
"fs_type".)


> Is anyone actually using inventory in
> its current form? 

I use it for mtsh.

Tim