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=27&rev2=28 Comment: Add a row to the matrix to make notes on our test coverage. One of the main UI (and high-level API) changes is that many operations on the path representing one half the move should be aware of the other half and perhaps require that both halves are acted on together: for example, an attempt to commit one half of a move without the other should error out. We need to go beyond simple path-based addressing now that we have 'move', because it affects two paths so we can't continue to assume a model where a path simply addresses 'the node' and a node has 'a path'. Idea: 'to' path identifies the move; 'from' path identifies any replacement at that path??? - ||<tablewidth="100%">Subcommand ||Ultimate goal ||Goal for 1.8 ||Trunk status || + ||<tablewidth="1287px" tableheight="1202px"12%>Subcommand ||<40%>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. ??? || || || + ||<12%>'''changelist ''' ||<45%>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 || + ||<12% style="text-align:right">''Test Coverage '' ||||||<45% style="text-align:center"> || + ||<12%>'''commit ''' ||<40%>Require both together. ||As per ultimate goal. ||Done || + ||<12% style="text-align:right">''Test Coverage '' ||||||<40% style="text-align:center;text-align:left">copy_tests.py 105 'attempt to commit the copied part of move' || + ||<12% style="text-align:right"> ||||||<40% style="text-align:center;text-align:left">copy_tests.py 106 'attempt to commit the deleted part of move' || - ||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 || + ||<12%>'''delete ''' ||<40%>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? || + ||<12%> ||<40%>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? || + ||<12% style="text-align:right">''Test Coverage '' ||||||<40% style="text-align:center"> || - ||diff ||Diff eventually needs to be upgraded to support moves, but how? ||Treat as copy & delete, for each path in tree? || || + ||<12%>'''diff ''' ||<40%>Diff eventually needs to be upgraded to support moves, but how? ||Treat as copy & delete, for each path in tree? || || + ||<12% style="text-align:right">''Test Coverage '' ||||||<40% style="text-align:center"> || - ||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 || + ||<12%>'''info ''' ||<40%>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 || + ||<12% style="text-align:right">''Test Coverage '' ||||||<40% style="text-align:center"> || - ||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). || || || + ||<12%>'''lock, unlock''' ||<40%>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). || || || + ||<12% style="text-align:right">''Test Coverage '' ||||||<40% style="text-align:center"> || - ||merge ||Nothing special -- For each path, apply changes to the actual/working node at that path. || || || + ||<12%>'''merge ''' ||<40%>Nothing special -- For each path, apply changes to the actual/working node at that path. || || || + ||<12% style="text-align:right">''Test Coverage '' ||||||<40% style="text-align:center"> || - ||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. || || || + ||<12%>'''move ''' ||<40%>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' || + ||<12%> ||<40%>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' || + ||<12% style="text-align:right">''Test Coverage '' ||||||<40% style="text-align:center"> || - ||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). || || || + ||<12%>'''resolve(d) ''' ||<40%>??? 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). || || || + ||<12% style="text-align:right">''Test Coverage '' ||||||<40% style="text-align:center"> || - ||revert ||See notes. ||Apply to either side independently, reducing the other side to a plain copy or delete. ||done || + ||<12%>'''revert ''' ||<40%>See notes. ||Apply to either side independently, reducing the other side to a plain copy or delete. ||done || + ||<12% style="text-align:right">''Test Coverage '' ||||||<40% style="text-align:center"> || - ||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 || + ||<12%>'''status ''' ||<40%>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 || + ||<12% style="text-align:right">''Test Coverage '' ||||||<40% style="text-align:center"> || - ||update, switch ||??? See notes. || || || + ||<12%>'''update, switch ''' ||<40%>??? See notes. || || || + ||<12% style="text-align:right">''Test Coverage '' ||||||<40% style="text-align:center"> ||
