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

Re: How to rearrange repo without "svn: Cannot replace a directory from within"

From: Ryan Schmidt <subversion-2008a_at_ryandesign.com>
Date: Sat, 15 Mar 2008 03:26:38 -0500

On Mar 14, 2008, at 22:26, Michael Harris wrote:

> Several years back I set up an svn repo for a project I am involved
> in. I didn't think too far ahead, and (I suspect) misread the
> documentation, so I set up a repo structured like this:
> <repo_root>
> |
> proj1 --+
> |-trunk
> |-branches
> |-tags
> In other words the repo has a single folder at its root (with the name
> of the project as its name), and this folder contains folders trunk,
> branches, tags.
> We are using svnserver and svn:// to access the repo. When I set up
> the svnserve configuration, I set <repo_root> as the root for
> svnserve, so the URL:
> svn://server.name/proj1/trunk
> points at the trunk of the repo, which is stored in
> /var/svn/repos/proj1
> Now, a couple of years later, I want to establish additional whole
> repos on the same server. With it set up the way it currently is, I
> can't do this because the server root points straight at the directory
> containing the existing repo. Of course I could change the server root
> so it is pointing one dir up the filesystem heirarchy but then the url
> would be:
> svn://server.name/proj1/proj1/trunk
> Which ain't so good. I realised that my main mistake was to create the
> proj1 directory inside the repo in the first place, so I want to
> rename trunk, branches and tags to be at the top level, then move the
> svnserver root up one as well.
> So, to try it out, I made a copy of my repo on another machine and
> tried the following steps:
> 1) Move trunks, branches and tags up a level so they are at the top of
> the hierarchy, like this:
> svn mv svn://server.name/proj1/trunk svn://server.name/trunk -m "SVN
> Repo reorganisation Pt1"
> (repeated for branches and tags as well).

Yup, sounds good to me!

At this point you need to take all existing working copies of e.g.
trunk and switch them so that they know to point to this new
different path *within* the repository, but that the repository
itself has remained at the same base location:

svn switch svn://server.name/trunk /path/to/wc

Same for any working copies of any branch or tag.

> 2) Stop the svnserve, edit the config file, and change the server
> root. Before, the server root was:
> /var/svn/repos/proj1
> After it became
> /var/svn/repos/
> Then restart svnserve. Everything seems fine, the URL for accessing
> the repo remains the same, and newly checked out WCs work fine.

After changing the repository root, you need to do the second kind of
switch, namely relocation. For each working copy of e.g. trunk, fix
the working copy to know that the repository itself has moved, while
the path within the repository has remained the same:

svn switch --relocate svn://server.name svn://server.name/proj1 /path/

Same goes for any working copies of any branch or tag.

> The problem is, working copies that were checked out before the change
> are no good any more! If I try to do even an svn st -u, I get the
> dreaded:
> svn: Cannot replace a directory from within
> Is there any way to make this change without ruining all existing
> working copies?

As I understand it, the reason for this problem is that, while to you
the URL before and after looks the same, to Subversion, the URL is
divided into two parts: the part that gets you to the repository, and
the part that defines the path within the repository, and you've
changed both of these parts. For the change in the path within the
repository, you need to execute a "switch"; for the change in the
part to the repository, you need to execute a "switch --relocate".

Or, of course, you can just check out new working copies.

To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-15 09:27:20 CET

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.