[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: Bert Huijben <bert_at_qqmail.nl>
Date: Fri, 18 Jan 2013 17:42:41 +0100

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: vrijdag 18 januari 2013 17:01
> To: Bert Huijben; 'Philip Martin'; dev_at_subversion.apache.org
> Subject: Re: svn commit: r1434913 -
> /subversion/trunk/subversion/libsvn_wc/wc_db.c
> 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.

This might not be as easy as it seems, unless you are already in working.
In BASE you still have to account for switched paths, while in WORKING that
would be different layers.

Moved away. Original location might have switched.... ouch, that might be
another can of worms for the conflict handling.

Moving back appears simple, and I really wish this was an easy fix. (I hope
we can get this in 1.8)

Other corner case:
Do we currently detect switched paths when handling move tracking... or just
mixed revisions?

Received on 2013-01-18 17:43:23 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.