On Mon, Sep 6, 2010 at 10:47 AM, Stefan Sperling <s...@elego.de> wrote: > On Mon, Sep 06, 2010 at 10:27:46AM -0400, Allen Williams wrote: >> I send this email out about once a month or so in what is becoming >> the vain hope I'll get a response... >> >> My subversion repository is in /var/svn. Somehow (and, yes, I'm new; >> I'm evaluating it), I've wound up with the following directory >> structure in my subversion repository: >> >> /var/svn/ >> var/svn/proj1 >> var/svn/proj2 >> var/svn/proj3.
Whare are the "db" subdirectories? Do you have 3 different working repositories, one at /var/svn/proj1, another at /var/svn/proj2, another at /var/svn/proj3? Remember, whatever the location of your Subversion repository, it's just a location of a database, one that can be located with a URL used by clients. It's name is actually arbitrary: it's association with a particular, and with branches and tags and a trunk under it, is entirely by convention. Any association with a particular project or set of projects is by your convention, it is not hardcoded anywhere except in your client configurations, that can be updated and altered with the "svn switch" command. >> In other words, to do a list of the repositories, I have to do: > > Here you say "repositories" > >> >> svn listfile:///var/svn/var/svn >> >> to get my projects listed. > > ... and here you say "projects". What do you really mean? > > svn list does not give you a list of repositories. > It gives you a list of folders inside of *a* repostitory. > So it looks like there is only one repository here, directly in /var/svn. > Inside of that repository, you have a versioned directory also called var/svn. > And inside there you have your proj1, proj2, and proj3 folders. That's how I'd interpret it. The switch of syntax from "/var/svn/" to the syntax of "var/svn/proj1" is very confusing. Does our friendly original poster mean that inside of his repo at file:///var/svn/, he has subdirectories for his pojects called var/svn/proj1, var/svn/proj2, var/svn/proj3, or something else equally outre? >> I've tried to do an svnadmin dump and load with --parent-dir, and that >> didn't work. This was the command line sequence after I had made a copy >> of the repository in /var/svn.sav: >> >> svnadmin dump /var/svn.sav> old_repos >> rm -r/var/svn/* >> svnadmin create /var/svn >> svnadmin load --parent-dir / /var/svn< old_repos And this is just..... oddness. That "rm -r/svn/* obviously would not work, due to the missing space between the "-r" and its targets. >> But, even though I had parent-dir as / (to try to eliminate one of the >> /var/svn's), I still got /var/svn/var/svn/projects. Ohh, deaar. OK, you've devinitely got subdirectories in your repository at var/svn/project1, var/svn/projects, etc. >> >> What is the way to do this? > > You want to remove the leading /var/svn components from all paths > in the dump file. See here: > http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.filtering > The part that starts with: > "At this point, you have to make a decision. > Each of your dump files will create a valid repository, but will > preserve the paths exactly as they were in the original repository." > is the interesting part you should read especially carefully. Yeah..... I think you've got it. Unfortunately, this can create serious historical preservation issues if code has started out in "higher level" directories and been migrated around. Allen? How bad would it be to simply move aside /var/svn/, export its contents, and create a clean new repository with the structure you want? I've often found it far simpler to set a cut-off date, notify users of the rebuild, and switch to a clean new layout with a clean new repo. It creates issues for people with un-integrated local changes, but it can be a lot simpler than getting cute with dumping and re-arranging components. A simple "README.txt" at the top of the repository, and setting it to read-only mode in an "archive" location, can be your savior here.