subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <comm...@subversion.apache.org>
Subject [Subversion Wiki] Update of "LocalMoves" by JulianFoad
Date Thu, 17 Jan 2013 20:06:50 GMT
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 JulianFoad:
http://wiki.apache.org/subversion/LocalMoves?action=diff&rev1=22&rev2=23

  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 ||For 1.8||Done like this? ||
- 
- 
- ||<tablewidth="100%">Subcommand ||Should (eventually, at least) ||Done like this?
||
- ||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. ??? || ||
+ ||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 ||
+ ||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. ||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. || ||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. || ||
+ || ||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. || || ||
- ||diff ||Diff eventually needs to be upgraded to support moves, but how; and what to do
for now? || ||
+ ||diff ||Diff eventually needs to be upgraded to support moves, but how; and what to do
for now? || || ||
- ||info ||Show 'Moved To' or 'Moved From', on the move root nodes... ||done ||
+ ||info ||Show 'Moved To' or 'Moved From', on the move root nodes... || ||done ||
- || ||... but *not* on children that haven't been sub-moved (Nested Moves paradigm). ||TODO
||
+ || ||... but *not* on children that haven't been sub-moved (Nested Moves paradigm). || ||TODO
||
- || ||Show 'Moved To' or 'Moved From' on a sub-moved child (Nested Moves paradigm). ||done
||
+ || ||Show 'Moved To' or 'Moved From' on a sub-moved child (Nested Moves paradigm). || ||done
||
- ||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).
|| ||
+ ||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. || ||
+ ||merge ||Nothing special -- For each path, apply changes to the actual/working node at
that path. || || ||
- ||move ||Applied to the 'from' side: just like any operation that operates on a working/actual
node that exists, this should operate on any replacement node; invalid if no replacement.
|| ||
+ ||move ||Applied to the 'from' side: just like any operation that operates on a working/actual
node that exists, this should operate on any replacement node; invalid if no replacement.
|| || ||
- || ||Applied to the 'to' side: transitive move, leaving no trace that the subtree was previously
moved to a different path. || ||
+ || ||Applied to the 'to' side: transitive move, leaving no trace that the subtree was previously
moved to a different path. || || ||
- ||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 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: should 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). ||
||
+ ||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 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: should 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.  For 1.8, apply to either side independently, reducing the other side
to a plain copy or delete. ||done ||
+ ||revert ||See notes. ||Apply to either side independently, reducing the other side to a
plain copy or delete.||done ||
- ||status ||Show a status line (or two lines) for the 'from' and/or 'to' paths independently.
See notes. As for 'info', show move info only on move-root nodes, and the 'from' path according
to to Nested Moves Paradigm. ||TODO||
+ ||status ||Show a status line (or two lines) for the 'from' and/or 'to' paths independently.
See notes. As for 'info', show move info only on move-root nodes, and the 'from' path according
to to Nested Moves Paradigm. || ||TODO ||
- ||update, switch ||??? See notes. || ||
+ ||update, switch ||??? See notes. || || ||
  
  
  
@@ -80, +78 @@

  === svn merge ===
  === svn move (on a moved node) ===
  === svn resolve (resolver) ===
- 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?
+ 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?
- 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.

Mime
View raw message