=========================================================================
 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'")