On the gpg-agent-password-store branch, remerge (that is, reverse-merge
and then merge again) r1146165, r1146496, r1146501. For some reason the
right set of changes was not merge into this branch when these revisions
were originally merged.
git-svn-id: https://svn.apache.org/repos/asf/subversion/branches/gpg-agent-password-store@1150760 13f79535-47bb-0310-9956-ffa450edef68
diff --git a/notes/moves b/notes/moves
new file mode 100644
index 0000000..cd9247c
--- /dev/null
+++ b/notes/moves
@@ -0,0 +1,135 @@
+
+ =========================================================================
+ This file sketches ideas about how we could improve move support in wc-ng
+ =========================================================================
+
+This file purposefully talks about 'moves' rather than 'renames'.
+This isn't about true renames as requested in issue #898.
+Rather, these ideas keep the add+delete concept while trying to make
+moves behave more in a way that one would expect if true renames were
+implemented.
+
+These ideas only cover local (client-side) moves in the working copy.
+They attempt to reuse as much existing code as possible, so new
+functionality will be implemented as part of existing copy/delete
+code paths unless doing so is not feasible.
+
+One significant change from how copies work is that moves will be tracked
+both ways, i.e. one can locate the add-half of a move if given the
+delete-half, and locate the delete-half if given the add-half.
+
+The goals are:
+
+ - Improve the behaviour for tree-conflicts involving a local move.
+ A "local move vs. edit" tree conflict should be automatically resolved.
+ Any tree conflict involving a local move should clearly indicate
+ so in its description, saying 'local move' instead of 'local delete'
+ or 'local add'.
+
+ - Prepare the client to be able to use the editor-v2 rename interfaces
+ when talking to the server.
+
+
+
+Notes regarding specific layers of Subversion follow below.
+
+
+== wc.db ==
+
+There already exist columns in the NODES table we use to differentiate
+moves from copies:
+
+ /* Boolean value, specifying if this node was moved here (rather than just
+ copied). The source of the move is specified in copyfrom_*. */
+ moved_here INTEGER,
+
+ /* If the underlying node was moved away (rather than just deleted), this
+ specifies the local_relpath of where the BASE node was moved to.
+ This is set only on the root of a move, and is NULL for all children.
+
+ Note that moved_to never refers to *this* node. It always refers
+ to the "underlying" node, whether that is BASE or a child node
+ implied from a parent's move/copy. */
+ moved_to TEXT,
+
+These will be used as described in their docstrings.
+
+
+== libsvn_wc ==
+
+Various wc_db and svn_wc interfaces will be extended for moves.
+New interfaces will be modeled after (and share code with) their
+existing copy or delete equivalents as much as possible.
+See r1146119 for an example of how existing code will be reused.
+
+Some existing interfaces will be extended, e.g. the _scan_addition()
+and _scan_deletion() interfaces will be extended to differentiate
+moved nodes from copied, added, and deleted nodes.
+
+### gstein: note that scan_addition() already returns status_moved_here,
+### and scan_deletion() returns a MOVED_TO_ABSPATH. these functions
+### should already do what you're asking (with bitrot and "untested"
+### caveats since I first implemented them).
+
+There might be some public API changes (TBD).
+
+We might require a working copy upgrade when going from 1.7 to 1.8,
+and only allow new move functionality to be used with 1.8 working copies.
+
+
+== libsvn_client ==
+
+This layer already uses existing svn_wc move APIs. For those callers
+APIs changes will hopefully be fairly transparent, apart from changes
+that enhance behaviour of move operations.
+
+Some code that is expected to change behaviour:
+
+ - commit: Commit will refuse to commit anything if only one half of
+ a move appears in the commit target list, or if only one half of
+ a move is picked up by recursion.
+
+ - revert: Revert will by default revert both nodes involved in a move,
+ independent of which half of the move is mentioned in the revert
+ target list. If only one half of a move is picked up by recursion,
+ revert will refuse to revert anything.
+ If the delete-half has been replaced by another node after
+ it has been deleted, revert will require both the add and delete
+ half to appear in the revert target list or be picked up by recursion
+ (i.e. the node replacing the delete-half has to be reverted explicitly
+ or via recursion).
+
+ - status: Status will provide information about both halfs of a move,
+ in a way that allows the user to tell that both halfs belong to
+ the same move operation.
+
+ - update/merge: Update and Merge will use move information to auto-resolve
+ the "local move vs. incoming edit" tree conflict scenario.
+
+ - diff: Diff will use move information to generate 'rename from' headers
+ when the --git option is used.
+
+ - patch: Patch will use move information to apply changes to files
+ which have been moved locally.
+
+Several public APIs may be bumped as their behaviour changes.
+For backwards compatibility, APIs released prior to 1.8 will continue
+to treat moves just like 1.7 and earlier releases did. (However, see
+also the note on working copy upgrades above, which might affect to
+what degree the APIs need to stay compatible.)
+
+
+== svn ==
+
+The svn client will present moves similar to but distinct from copy
+operations. E.g. it might show moves like this:
+
+$ svn status
+A + foo
+ > moved from 'bar'
+D bar
+ > moved to 'foo'
+$
+
+(If the above is done, we should also show copyfrom for normal copies
+this way, but as "copied from '%s'")
