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).
