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

Re: Relocate Problem

From: Scott Palmer <scott.palmer_at_2connected.org>
Date: 2005-05-25 15:35:57 CEST

On May 24, 2005, at 10:25 PM, Ben Collins-Sussman wrote:

> On May 24, 2005, at 8:54 PM, Scott Palmer wrote:
>> (The first time I did a "switch" it freaked me out because I
>> wasn't expecting to pull in changes and wasn't ready to deal with
>> conflicts resulting from the merge.)
> What were you expecting?

I was expecting to continue working as if nothing had happened :). I
just didn't make the connection that my WC was going to be changing
and thought I did something wrong when I saw the incoming updates.
My local changes weren't at a stable enough point and the merge
wasn't going to go well.

I needed the switch because the location of the project within the
repo changed, and that is all I wanted to change about my working
copy. I understand now how it isn't that simple, because the
versions of files in the repo that were copied to the new location
may be newer than the BASE revision of the file in my working copy,
and therefore there would be no possible BASE unless the update
But... I'm thinking with true renames that this should be
avoidable... the URL in my WC could be changed to point to the new
location, possibly with some funky @rev thing.. , AND the revision
would point to the actual revision of the resource that corresponds
to my current BASE. (Deleted and added resources might still be an


REPO rev 3:

svn co svn://server/trunk/MyProj MyProj
At revision 3

svn mv svn://server/trunk/MyProj svn://server/trunk/ProjectX

rev 4:

svn switch svn://server/trunk/ProjectX
In my WC the BASE of fileA would become
revision 3 of svn://server/trunk/ProjectX/fileA_at_4

Does that make sense?

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 25 15:37:33 2005

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

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