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
happened.
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
issue.)
E.g.
REPO rev 3:
/trunk/MyProj/fileA
svn co svn://server/trunk/MyProj MyProj
At revision 3
svn mv svn://server/trunk/MyProj svn://server/trunk/ProjectX
rev 4:
trunk/ProjectX/fileA
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