monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] automate inventory


From: Derek Scherger
Subject: [Monotone-devel] automate inventory
Date: Sun, 09 Apr 2006 22:53:25 -0600
User-agent: Mozilla Thunderbird 1.0.7 (X11/20060205)

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.

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?

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? Is anyone actually using inventory in
its current form? I'm pretty sure we have at least one bug about the "/" suffix thing.

Cheers,
Derek






reply via email to

[Prev in Thread] Current Thread [Next in Thread]