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 _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
