Renaming a checked out repository path

[Torsten Landschoff <to...@debian.org>]

Hi *, 

As I am reorganizing some subversion repositories today I stumbled
across a "misfeature" in subversion. Basically I was splitting a trunk
directory from "trunk" to "trunk-2.1" and "trunk-2.2" for different
upstream version of the software I am working on. 

Now I was curious what would happen to checked-out copies. After
renaming I got the following error message from svn update:

	svn: Cannot replace a directory from within

Well, I wondered why that is as the name of the WC is not linked to the
name in the repository. Anyway I tried

	cd ..
	svn update WC

with the same result. 

While this is not a big deal in this case I wonder if svn shouldn't be
able to automatically do the required switch during the upgrade. Sending
every developer an email to switch is tedious work in case you have more
than a hand ful developers.

Thoughts?

Greetings

	Torsten

Re: Renaming a checked out repository path

[Ben Collins-Sussman <su...@collab.net>]

On Apr 1, 2005, at 6:40 AM, Torsten Landschoff wrote:

> Hi *,
>
> As I am reorganizing some subversion repositories today I stumbled
> across a "misfeature" in subversion. Basically I was splitting a trunk
> directory from "trunk" to "trunk-2.1" and "trunk-2.2" for different
> upstream version of the software I am working on.
>
> Now I was curious what would happen to checked-out copies. After
> renaming I got the following error message from svn update:
>
> 	svn: Cannot replace a directory from within
>

Subversion doesn't have moves, it has copies and deletes.  So what you 
did was copy the trunk directory, then delete it.  So when you 'svn 
update' a working copy of trunk, the server wants to delete the whole 
working copy.   But that's not allowed, and what you see is that 
bizarre error message.

Subversion has no way of expressing "true moves" yet, that's the next 
thing we'd like to work on.  If it did, then the server might be smart 
enough to send 'switch' operations during updates, instead of "delete;  
add" like it does now.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

RE: Renaming a checked out repository path

[Dale Worley <dw...@pingtel.com>]

> From: Torsten Landschoff [mailto:torsten@debian.org]
>
> As I am reorganizing some subversion repositories today I stumbled
> across a "misfeature" in subversion. Basically I was splitting a trunk
> directory from "trunk" to "trunk-2.1" and "trunk-2.2" for different
> upstream version of the software I am working on.
>
> Now I was curious what would happen to checked-out copies. After
> renaming I got the following error message from svn update:
>
> 	svn: Cannot replace a directory from within
>
> Well, I wondered why that is as the name of the WC is not
> linked to the
> name in the repository.

The problem is that Subversion does not (yet) have true renames.  What
appears to be a rename is a copy from the old name to the new name, followed
by a delete of the old name.  Thus, when you try to update, the forward
history of "trunk" is "it is deleted in rev 435".

There are probably other, independent complications, but currently there is
no reason to expect Subversion to correctly update a WC when it must rename
directories containing locally-changed files.

Dale


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org