Thomas Keller <[EMAIL PROTECTED]> writes: > Stephen Leake schrieb: >>> So, its actually this way: If a file is dropped (status "dropped"), >>> 'path' is the path in the old roster. If a file is added (status >>> "added"), 'path' is the path in the new roster. If a file is renamed, >>> 'path' is either an old or a new path, depending if there is a >>> 'new_path' stanza (then its an old path) or an 'old_path' stanza (then >>> its a new path). >> I find this confusing. >> Perhaps it would be less confusing if we change it to work the way I >> stated it above; then the output of 'automate inventory' is more >> directly related to the state of the filesystem and manifests. > > I think the 'path' usage is quite understandable. It never brought up > any complaints even for the old, line-based format, where the path had > the same "multi-meaning". But we may want to work out old_path and > new_path a bit, or, if it is altogether too confusing, leave it out > and display node ids as it was implemented before.
The node ids were not less confusing; we are making progress! >> Although I'm not sure what that means for missing and dropped files; >> they don't exist in the filesystem. > > Thats why the output interweaves entries from the old and the new roster. > >> Perhaps 'path' should be absent if fs_type is 'none'. And perhaps 'path' >> should be 'fs_path', to be consistent with 'old_path'. >> Then the stanza should start with 'status', since there needs to be a >> line that reliably starts a stanza; parsers should not rely on >> whitespace. > > Personally, I don't like this idea. IMHO a stanza should always start > with something that identifies the upcoming data, like a path, or at > least a node id or something. The status string is not at all usable > for that. In general, I agree; the first line of a stanza should indicate what will follow. In this case, I think the "status" line fills that role better than "path", since "fs_path", "old_path" and "new_path" are undefined when the current node is not in the corresponding source. We could use "fs_type", "old_type", or "new_type" as the first line, since those are always well defined. But "status" is more meaningful; it defines what actions are available for the current node (commit, revert, remove, display diff, declare a rename, etc). We could also output the node_id. But that is not actually useful for the external tool, so I don't think that's a good choice. For nodes that appear in all three sources, the status line says "here is a node that appears in all three sources": status "known" fs_type "file" fs_path "unchanged" It is sufficient to just output 'fs_type' and 'fs_path', since the status line indicates that the others are the same. status "known" "changed_content" fs_path "patched" fs_type "file" (here I've merged the "changes" line into the "status" line; I think that's a good idea) For a node that only appears in the old manifest, the status line says that: status "dropped" old_path "dropped" old_type "file" For a node that appears in the new and old manifests, but not in the filesystem: status "missing" old_type "file" old_path "missing" For a node that appears only in the new manifest: status "added" "missing" new_type "file" new_path "missing" This is a fairly large change in the appearance of the output, but I suspect it is _not_ a large change in the code (it should be simpler), and it will resolve the ambiguous cases that have been presented so far. And it will be simpler for a tool to interpret. One way to look at this is as a change of focus, from "what do I know about this file" to "what can I do with this node". 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. Another point; this interface is for tools, not people. So if a user likes combining one of "fs_path", "old_path" and "new_path" into a display field "path" (as the current 'automate inventory' output does), they can have the tool do that (and I suspect Emacs DVC will do that). 'automate inventory' should present the information to the tool in a way that is as simple and un-ambiguous as possible. -- -- Stephe _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
