subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Schmidt <>
Subject Re: changing DIR structure of SVN dump
Date Tue, 10 Jan 2012 15:55:54 GMT
On Jan 10, 2012, at 08:39, Shaaa wrote:

> So I am trying to move my repos to a new server. Problem is the old
> guy did a really strange setup. Basically, in order to access the
> repos I would have to use the following uri
> file:///var/svn/repos/mysite/trunk/project1/trunk On the new server I
> want to change it to file:///var/svn/repos/project1/trunk but I dont
> want to show the changes in the revs. I have tried the following:
> svnadmin dump /var/svn/repos > mydump
> svnadminfilter include trunk < mydump > newdump
> svnadmin mkdir file:///var/svn/repos/myproject1
> svnadmin load /var/svn/repos --parent-dir myproject1 < newdump
> but it gives me the following URI:
> file:///var/svn/repos/myproject1/trunk/myproject1

You need to distinguish between:

1. the path of the repository on the old server's disk
2. the path of the repository on the new server's disk
3. the url through which the repository is accessed on the old server
4. the url through which the repository is accessed on the new server
5. the path of things inside the repository

Hopefully you are not actually accessing repositories via the file:/// protocol over for example
a file share, and are instead running an apache server and accessing it over the http:// or
https:// protocol, or an svnserve server and accessing it over the svn:// protocol, or have
ssh access and are accessing it over the svn+ssh:// protocol.

When making any change to your setup, you should change as few things at a time as possible.
For example, change the paths within the repository (by doing "svn mv", or a dump/filter/load
cycle), without changing where the repository is on disk or the URL used to access it. Or,
move the repository to a new server, without changing its contents. Though I understand that
the new server might have a different disk layout than the old server.

So, let's take a look at your situation:

> svnadmin dump /var/svn/repos > mydump

This says the repository was on disk at /var/svn/repos.

> svnadminfilter include trunk < mydump > newdump

There is no command "svnadminfilter"; perhaps you meant "svndumpfilter"?

Based on the URLs you showed above, the repository doesn't contain a directory "trunk"; it
contains a directory "mysite" which contains a directory "trunk". So the newdump shouldn't
contain anything.

> svnadmin mkdir file:///var/svn/repos/myproject1

There is no such command "svnadmin mkdir"; did you mean "svnadmin create"? That would be odd
though since you showed earlier that /var/svn/repos is a repository; you don't create repositories
inside other repositories. So perhaps you meant "svn mkdir" instead?

> svnadmin load /var/svn/repos --parent-dir myproject1 < newdump

You are loading a new dumpfile into the same old /var/svn/repos repository?

There appears to be significant confusion. Some of what I wrote above may be wrong, since
it is based on what you said, and we already know two lines of your transcript cannot be correct.
Perhaps we should start with:

1. Do you have one repository or multiple repositories? Do you want to change that?
2. What is the path of the repository or repositories on disk? Do you want to change that?
3. What is the path of the items inside the repository? I presume you at least want to change
that, to remove the doubled "trunk" directories.

Finally, note that if you really want to dump/filter/load and thus not change the revision
numbers, what that means is that you are rewriting the repository's history (i.e. changing
the contents of (at least some of) those revisions). As a consequence, you must ensure that
you assign the new repository a new UUID, and thus everybody who has a working copy will have
to throw it away and check out a new one. Of course while you are doing your work to rewrite
the repository history (while you are running dump / filter / create / load), you'll have
to disable write access to the repository. It's often more convenient to just "svn mv" things
and accept a slightly "dirtier" history than to go through these steps; some would even argue
the history is not dirty in this case; instead, it's accurate, in that it shows what was moved,
when, and by whom (and if you write a good commit message, why).

View raw message