Re: [Monotone-devel] Changes in nvm.basic_io.inventory

[Derek Scherger]

Stephen Leake wrote:
> Since monotone supports renaming, the notion "this file" is often
> ill-defined. But "this node" is always well-defined, as are the
> operations that can be performed on it.

One thought that along these lines is that perhaps we should change the
entire focus from paths to nodes:

node "1234"
old_name "foo"
new_name "bar"
old_content [1234...]
new_content [5678...]
status "renamed" "patched"

node "5678"
old_name ""
new_name "foobar"
old_content []
new_content [1234]
status "added"

node "9876"
old_name "foobar"
new_name ""
old_content [1234]
new_content []
status "dropped"

node "1313"
name "asdf"
status "unknown"

etc.

For "nodes" that don't exist in either roster the id's would presumably
be temporaries (see temp_node_id_source).

This clearly isn't fully thought out but seems like it might be worth
considering. I'm not sure how we would want to represent the
filesystem's name for unknown/ignored "nodes" and I wonder about
combining old/new things into one keyword with both old and new values.

node "1234"
names "foo" "bar"
content [1234] [5678]
status "renamed" "patched"

Perhaps instead of old_name and new_name lines we have lines like

added "name"
dropped "name"
renamed "old_name" "new_name"

and for nodes that have not had name changes we simply list

name "name"

then the corresponding status line might contain "known", "unknown",
"ignored", "missing" etc.

Yet another option might be to always list both old_name and new_name
lines and just let them be the same thing in some cases. Note that in
the case of a drop + add on the same name we would have two different
node ids:

node "1234"
old_name "foo"
new_name ""
status "dropped"

node "5678"
old_name ""
new_name "foo"
status "added"

Thoughts?

Cheers,
Derek