[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 18 Jan 2013 16:25:04 +0000 (GMT)

Stefan Sperling wrote:

> On Fri, Jan 18, 2013 at 04:52:42PM +0100, Stefan Sperling wrote:
>> like 'svn mv A B; svn mv B A' earlier, which
>> also doesn't make sense).
>
> What I mean here is that I think this command sequence should
> result in a no-op as far as the move operation is concerned.
>
> Rather than running a copy+delete of B->A again as the current implementation
> does, I think svn should undo the A->B move in a way that preserves any
> existing modifications within B, so that the squence:
>
> svn mv A B
> svn mv B A
>
> is a no-op, and the sequence:
>
> svn mv A B
> # make changes in B
> svn mv B A
>
> results in the equivalent of:
>
> # make changes in A
>
> I'm considering trying to work on this soon.

+1.  This is the only sensible behaviour for the user.  The issue #3429 [1] ("svn mv A B; svn mv B A" generates replace without history) was 'fixed' for 1.7 in a way that made the node 'Replaced', and even there I hope we can agree that was a pretty marginally acceptable solution for 1.7.  We could have done it 'properly' there, but didn't.  Now that we have local moves, it would be so, so wrong to keep doing that 'Replaced' thing.

I added a sentence to this effect in the 'Subcommand' table in <https://wiki.apache.org/subversion/LocalMoves>: "If moved back to its own 'from' path, it should become as if it had never been moved.".

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

- Julian
Received on 2013-01-18 17:25:41 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.