Subversion - Merging Repositories

Question

When I first setup the SVN structure for my different projects, I decided to place each different project in a separate repository.

This has worked well for a while, but I'm staring to think that I would like to merge all of those repositories into one overall "company-wide" repository so when I have employees check out the source code, they can just checkout from the top and have all the code from all the different projects.

I found the svn-merge-repos command online, but not a lot of user feedback or helpful tips for using it. Is this the best way to join repositories so I don't loose my history data, or is there a better way? Are there any pitfalls that I should watch out for?

Thanks.

Answer 1

You can use svn-merge-repos.pl, or you can merge several repository dumps with SvnDumpTool merge, and then load the resulting dump with svnadmin load --ignore-uuid.

Be aware that all revisions will be renumbered.

Check the merge section of SvnDumpTool readme.

Answer 2

If you just want the repositories to look unified, you can use the svn:externals property, so that a single checkout will pull in code from all of the existing repos.

Answer 3

Please please please don't force your users to checkout an entire repository to get things to build. This is harking back to the old sourcesafe model and it wasn't good then.

Having one repository per project is fine. If project1 needs code from project2, add an "svn:externals" property to the trunk of project1 which brings project2 into a sensible place under project1's directory. If project2 needs project3's code, it too can have an external property and bring the code in underneath it.

It's actually best if the externals references always points to a tag or a specific revision, but I'll let you off pointing to trunk if you avoid the "one huge projectspace" issue.

If you work with externals, anyone can just checkout the project they want and automatically get all the dependencies and just build away - just as you want. All their code is self-contained in a single working directory that contains just what they need, they can checkout multiple versions of multiple projects into separate working directories without wasting space and still keep track of what the hell is going on.

It may require some minor refactoring of your workspace if project1 expects to find project2 outside of it's project folder rather than inside, but that's a minor tweak in the grand scheme of things.

If you really have your heart set on a single repository, that's fine too (that's what we use at my workplace, and at home, come to think of it), however do ensure that you have a structure where each project has its own tags, trunk & branches folders, and that checking out the trunk of project1 is all you need to do to get the code for project1 to build.

Finally, if you really need a funky layout for your projects, you can add an extra single repository, which is basically a meta-repository. This repository will contain 1 directory per top level project (with trunk tags & branches), and using externals, reference all the other projects and build the funky workspace in exactly the way you'd expect.

This way, by adding the extra repository, you get all the benefits of checking out and building in one step and at least stand a chance of managing situations where changes required for project1 break project3 because of code shared with project2, and you suddenly need to get an emergency fix out for project3.

Answer 4

Don't do that. As @KeithB says, referencing them using svn:externals should be fine.

It's better to maintain each project on it's own repository, so you can archive old projects easily, and also for a better integrity.

For example, the apache foundation maintains a single repository for all it's projects (I don't know if it is replicated from other repos or it is the live one). Right now, it's history weights 700k+ revisions. I wouldn't like to see this monster going kaput.

Answer 5

I recently had to do something similar and what I did was, in essence:

• svnadmin create X:\Repositories\RepositoryC
• svn mkdir http://localhost:8080/svn/RepositoryC/branches --message "Added the branches folder."
• svn mkdir http://localhost:8080/svn/RepositoryC/tags --message "Added the tags folder."
• svn mkdir http://localhost:8080/svn/RepositoryC/trunk --message "Added the trunk folder."
• svn mkdir http://localhost:8080/svn/RepositoryC/trunk/A --message "Added the trunk\A folder."
• svn mkdir http://localhost:8080/svn/RepositoryC/trunk/B --message "Added the trunk\B folder."
• svn checkout http://localhost:8080/svn/RepositoryC RepositoryC
• svnadmin dump X:\Repositories\RepositoryA > RepositoryA.dmp
• svnadmin dump X:\Repositories\RepositoryB > RepositoryB.dmp
• svnadmin load X:\Repositories\RepositoryC --parent-dir trunk\A < RepositoryA.dmp
• svnadmin load X:\Repositories\RepositoryC --parent-dir trunk\B < RepositoryB.dmp
• svn checkout http://localhost:8080/svn/RepositoryC RepositoryC

NB: The above code assumes that on the machine that hosts your Subversion repositories, the repositories exist on X:\Repositories and the URL to the Subversion server is http://localhost:8080 and the one is in the working folder.

At this point you will end up with RepositoryC that has RepositoryA and RepositoryB in it under trunk\A and trunk\B respectively. Your working folder with also contain a folder called RepositoryC that contains a checkout out the RepositoryC.

You can now move things around in RepositoryC to unify the project structures of the two repositories RepositoryA and RepositoryB.