Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "LocalMoves" page has been changed by pburba: http://wiki.apache.org/subversion/LocalMoves?action=diff&rev1=26&rev2=27 Comment: Add a link to a relevant thread ||<tablewidth="100%">Subcommand ||Ultimate goal ||Goal for 1.8 ||Trunk status || ||changelist ||Require both together? Automatically select both sides? Neither: The 'to' side should represent the move; the 'from' side shouldn't need to be assigned to a changelist in order to be operated on by that changelist; rather, the 'from' side represents any replacement at that path. ??? || || || ||commit ||Require both together. || ||done || - ||delete ||Applied to the 'from' side: delete the replacement if there is one (this might be the 'to' side of another move); don't affect the move. ||discussing||done || + ||delete ||Applied to the 'from' side: delete the replacement if there is one (this might be the 'to' side of another move); don't affect the move. ||discussing ||done || - || ||Applied to the 'to' side: revert the move; change the 'from' path to a simple deleted(rather than move-away); keep it replaced if it was replaced. || ||errors out?|| + || ||Applied to the 'to' side: revert the move; change the 'from' path to a simple deleted(rather than move-away); keep it replaced if it was replaced. || ||errors out? || - ||diff ||Diff eventually needs to be upgraded to support moves, but how? ||Treat as copy & delete, for each path in tree?|| || + ||diff ||Diff eventually needs to be upgraded to support moves, but how? ||Treat as copy & delete, for each path in tree? || || ||info ||On each move root node (only), show 'Moved To' or 'Moved From' (or both if node is moved-away replaced by moved-here). || ||also shows on all children || ||lock, unlock ||Nothing special -- As we can only lock paths that exist in the repo, in general we can't lock the 'to' side of a move (although we could do when it is a replacement). || || || ||merge ||Nothing special -- For each path, apply changes to the actual/working node at that path. || || || ||move ||Applied to the 'from' side: operate on any replacement node; invalid if no replacement. Should be similar to 'delete' in this regard, and should have some commonality with any other operation that operates on a working/actual node that must exist. || || || - || ||Applied to the 'to' side: transitive move, leaving no trace that the subtree was previously moved to a different path. If moved back to its own 'from' path, it should become as if it had never been moved. || ||move to 'from' path gives bad status 'R + foo // > moved from foo // > moved to foo'|| + || ||Applied to the 'to' side: transitive move, leaving no trace that the subtree was previously moved to a different path. If moved back to its own 'from' path, it should become as if it had never been moved. || ||move to 'from' path gives bad status 'R + foo // > moved from foo // > moved to foo' || ||resolve(d) ||??? At the moment, a move conflict is flagged on the 'from' side I think. But that's no good if there's a replacement that may have a conflict (?), and anyway we should provide the UI on the side that the user can see (?). Applied to the 'to' side: resolve the move conflict? Applied to 'from' side: resolve any conflict on the replacement node? (Applied to either side: automatically (silently) operate on both sides? No, that would interfere with resolving a conflict on the replacement on the moved-away side.) See section on conflicts (TODO). || || || ||revert ||See notes. ||Apply to either side independently, reducing the other side to a plain copy or delete. ||done || ||status ||On each move root node (only), show the historical 'D' or 'A +' line and then an extra line with '> moved to xxx' or '> moved from xxx' (or both lines if node is moved-away replaced by moved-here, or a single '> swapped with xxx' line if moved-to == moved-from). See notes. As for 'info', show the 'from' path that is within the 'to' side of the parent move (see Nested Moves). || ||shows a 'D' line for every moved-away child || @@ -79, +79 @@ Using theirs-conflict currently resolves a conflict from a local move by converting it to a copy. Is there a real use case for this? Doesn't work after a merge with a local move? Should it? === svn revert === - Currently silently converts the other half into a simple delete or simple copy if you only run it on one half of the move. As stsp points out, that's easy to explain. + Currently silently converts the other half into a simple delete or simple copy if you only run it on one half of the move. As [[http://svn.haxx.se/dev/archive-2011-08/0239.shtml|stsp points out]], that's easy to explain. Should it require 'force' for that, since the user quite likely doesn't want to break the move?
