RE: 'svn mv' between disjoint wc's of disjoint subtrees

I don’t think we can keep the moved-to tracking working between multiple
dbs, but I don't think we can just break that you can ‘svn mv’ data between
working copies.

Maybe it should still work as add+delete in that case, but beaking
scenarios is for 2.0, not for 1.8.

We shouldn’t break user scenarios... especially if the only reason is to
keep things easy, to release something fast.

In those cases we should delay the feature to do things properly.

Bert

Sent from Windows Mail

 *From:* Johan Corveleyn <jcorvel_at_gmail.com>
*Sent:* January 8, 2013 9:57 AM
*To:* Daniel Shahaf <d.s_at_daniel.shahaf.name>,dev_at_subversion.apache.org
*Subject:* Re: 'svn mv' between disjoint wc's of disjoint subtrees

On Tue, Jan 8, 2013 at 1:56 AM, Stefan Sperling <stsp_at_apache.org> wrote:
> On Tue, Jan 08, 2013 at 02:28:34AM +0200, Daniel Shahaf wrote:
>> Over at infra@ we ran into an issue where an 'svn mv' between two
>> disjoint working copies --- each wc is of a different subtree of trunk
>> --- became a mv without history. I couldn't reproduce that one with
>> a 1.8-dev build. However, I ran into an issue with 'status' handling
>> such moves:
>>
>> % $svnadmin create r
>> % $svn mkdir -qmm file://$PWD/r/{foo,bar}
>> % $svn co -q file://$PWD/r/foo
>> % $svn co -q file://$PWD/r/bar
>> % touch foo/iota; $svn add -q foo/iota; $svn ci -qmm foo/iota
>> % $svn mv foo/iota bar/kappa
>> A bar/kappa
>> D foo/iota
>> % $svn st -q foo bar
>> D foo/iota
>> > moved to foo/kappa
>> A + bar/kappa
>>
>> This output appears to be wrong: the 'moved to' is wrong because the
>> move destination is ^/bar/kappa, not ^/foo/kappa; and the "moved from"
>> output is completely absent.
>
> There is code to perform cross-wc.db copies, a remnant from the pre-1.7.0
> times when wc-ng was still using multiple .svn directories.
> I believe that is what makes the copy work though I'm not even sure we
> intentionally support copies between disjoint working copies.
>
> There also used to be checks for half-recorded moves, in which case the
> status output would simply hide the fact that a delete/copy was part
> of an incomplete move (i.e. where node A claims it was moved to B but B
> has no back-pointer to A). With those checks in place you would just
> see a copy + delete at the UI level.
> I believe these checks were taken out, and the intent was to make it
> impossible to record incomplete moves in the first place. Apparently
> this particular case was overlooked when this was done. Or perhaps
> this is still a TODO item. AFAIK a move still involves two wc.db
> transactions, one for the delete and one for the copy, and I believe
> there were plans to use a single transaction instead.
>
> Off-hand I'm not quite sure what the correct behaviour should be.
> Should the move just error out? We certainly cannot record it as a move
> within the same wc.db. So we should probably require the user to run
> 'svn copy' and 'svn delete' instead, provided cross-WC copies are
> supposed to be supported.

Well, cross-wc.db commits are certainly supposed to work since 1.7:

- issue #2381 [1] (Cannot commit multiple WC paths which lack a common
parent directory), fixed in r1091928 by Bert.

Does that mean cross-wc moves should work? I think they do in 1.7
(some of my colleagues do this sometimes, when they move some code
from module A to module B, and they don't have the common parent
directory checked out, but just the two disjoint working copies).

If they work in 1.7, it would certainly be desirable to keep them
working (with the "movedto" support) in 1.8. And if they don't already
work in 1.7, well, that would be a nice enhancement then :-).

[1] http://subversion.tigris.org/issues/show_bug.cgi?id=2381

--
Johan