phi...@apache.org writes:
> Author: philip
> Date: Wed Mar 14 17:13:42 2012
> New Revision: 1300647
>
> URL: http://svn.apache.org/viewvc?rev=1300647&view=rev
> Log:
> On multi-layer-move branch, remove an excessively strict check and allow
> a node to be both moved_to and moved_here. copy_tests 45 and 46 move a
> node and move it back and expect the result to be a replace; recording
> the moves for such a case seems reasonable.
>
> All regression tests now pass on the branch.
Current trunk records moved-to/from data, with moved-to in the base
nodes in wc.db. It does this using the same DB schema as 1.7 and there
has been no wc format bump since 1.7. This means both 1.7 and trunk
clients can operate on the same working copy. 1.7 doesn't record
moved-to/from, and ignores and moved-to/from recorded by trunk treating
moves as copy+delete.
The existing trunk base node system has problems that are fixed by the
multi-layer-moves branch. It is now time to reintegrate the branch but
it is not compatible with the existing trunk moved-to/from storage,
although no schema change is involved.
$ svn mv wc/A/g wc/g # using trunk
A wc/g
D wc/A/f
$ svn st wc # using trunk
D wc/A/f
> moved to wc/g
A + wc/g
> moved from wc/A/f
If we now use the branch on that working copy:
$ svn st wc
D wc/A/f
A + wc/g
The moved-to/from is lost, a bit like 1.7 which simply doesn't consider
moved-to/from
The question I have is whether the branch should bump the wc format. I
would not go as far as writing code to migrate the moved-to/from, the
code would simply throw an error during upgrade if any base-node moves
were present.
In general wc format bumps are cheap, but this is the first format bump
since 1.7 which makes it more expensive: it stops the stable client
being able to access trunk working copies. I've been assumming that
there will a format bump at some time before 1.8, perhaps it should be
now?
--
Philip
