Thomas Keller <[EMAIL PROTECTED]> writes: > Stephen Leake schrieb: > >>> $ mtn rename foo tmp >>> $ mtn rename bar foo >>> $ mtn rename tmp bar >> So if the user had done 'automate inventory' between each of these >> steps, it would have been clearer. >> Let's see; 'path' gives the name in the current workspace filesystem. >> 'new_path' gives the name in the current (uncommitted) revision >> manifest. 'old_path' gives the name in the committed revision >> manifest. > > Thats not totally true. 'path' can also point to an old or a new path. > F.e. if an item is dropped, you get the following output: > > path "dropped_file" > old_type "file" > fs_type "none" > status "dropped" > > The output for added items is similar: > > path "added_file" > new_type "file" > fs_type "file" > status "added" "known" > > 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. Although I'm not sure what that means for missing and dropped files; they don't exist in the filesystem. 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. You've also confused 'stanza' with 'line'; I think 'stanza' means 'group of lines'? I need to write that up ... > Now the interesting question here is actually what 'path' is if the > item was both, rename source and rename target. Can't answer this > properly right now. If 'fs_path' is simply the current name in the filesystem, this is resolved. > As a sidenote, I thought about having two rename states, > "rename_source" and "rename_target", but then decided against this > because what the item actually is, is implicitely told by old_path > and new_path (just like before through the node ids). But maybe its > not that a bad idea to make this more explicit, I dunno. In general, I think it's better to be explicit, as long as it doesn't get overly verbose. -- -- Stephe _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
