Derek Scherger <[EMAIL PROTECTED]> writes: > 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.
This is similar to my suggestion. Note that the node id is not actually useful for anything, so there's not much point in outputting it. In this case, it just serves as a reliable first line in the stanza; 'status' could be first instead. Hmm. It just occurred to me that a reliable _last_ line is just as good as a reliable _first_ line, as far as dividing lines into stanzas goes. Although it would be good to standardize whether the first or last line is reliable for _all_ basic_io output, so stanza-based parsers can be standardized. Emacs DVC doesn't use the content info (at least for now); what use do you forsee for it? > For "nodes" that don't exist in either roster the id's would presumably > be temporaries (see temp_node_id_source). Right. Which may be a problem for the unit tests, since the temporary node ids may not be repeatable across all hosts (for example, 32 bit vs 64 bit may be a problem). > 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" The filesystem path for these is clear (they are existing files); what's not clear is the node id (it's a temporary). The only piece of information that is well-defined for _all_ nodes is the status. > 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. In this case, the tool has to read the status line first, in order to know what the other lines mean, or what other lines to expect in the stanza. On the other hand, if the tool reads the whole stanza, and then processes it, the order of lines doesn't actually matter. > 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? These are interesting suggestions. I don't think we should change the output so drastically without a good reason; a lot of work has gone into the current format. I'm not clear these formats are significantly better than your first one above. By "better" I mean "easier for a tool to parse, less ambiguous". To resolve these issues, I think it would help to have more examples of tools that will use the 'automate inventory' interface. I'm focussed on Emacs DVC; what other tools plan to use this? -- -- Stephe _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
