9.2. Planning for Growth Because Subversion repositories are so innately malleable, there is a tendency to ignore long-term repository growth and just plan a repository for what works best immediately. After all, you can always move things around later, right? To a certain extent, that's one of the great advantages of Subversion. In most cases, you can defer much of your long-term planning to the long term, and just do what works "right now." However, if you in fact do a bit of long-term planning up front, you may find that you save yourself a few headaches in the long run. To make sure that you've planned well for future growth, make sure that you ask yourself the following questions before laying out a new Subversion repository. Is this one project or many? If your repository is made up of a single project, you have little to worry about. You can easily put everything at the top level, and then move it down into a subdirectory at a later date if you add more projects. Such a move should cause few problems for people, and will make the repository simpler until a second project is added. Of course, if you have definite plans for a second project in the near future, you may be better off starting off with everything in subdirectories, just to save everyone the small headache a change will cause. If you start off with multiple projects instead, it's easy to begin with each project in its own individual subdirectory, which will make adding new projects down the road much less painful (it will also make it simpler to delete projects, if the need ever arises). If the repository includes multiple projects, are those projects likely to share data? This is an important question to ask, mainly for the case where the answer is "no"the reason being that if you plan to have many unrelated projects, you might want to consider creating multiple repositories, instead of putting all of your projects in a single repository. This has the advantage of helping you prevent a repository that gets too big (although Subversion has no fixed limit on repository size), as well as allowing you to move an individual project to a different server if you so desire. The downside to multiple repositories is that Subversion currently has no way to perform a copy or merge that crosses from one repository to another. In other words, if you need to take data from one repository and replicate it in another, you will have to perform the copy by using a filesystem copy from one working copy to another, which will not preserve history for the copy. If a merge is necessary, it will have to be done by hand. Will individual projects be primarily worked on by one developer, or many? This question isn't quite as important as the previous one, but it is a good one to consider when laying out a repository. The answer helps to determine the scale at which you need to plan out the organization of the repository. If each project will exist on its own, with interaction only by one person (or a small group), there may be little need to impose a repository-wide standard on the way that particular project is laid out. On the other hand, if the repository will be accessed and modified by a large team of users, the project will almost certainly benefit from an up-front plan for laying out the directory structure, including how branches and tags will be organized.
9.2.1. Merging and Splitting a Repository After you've decided on using a single repository or multiple repositories, it's usually best to stick with that choice. Sometimes needs change, though, and occasionally you will want to combine two repositories into one, or split a single repository in two. Fortunately, Subversion provides ways for you to do both. Merging Two Repositories If you have two repositories that you would like to combine into a single repository, your best solution is to dump one of the repositories (using svnadmin dump) and then load it into the other one (using svnadmin load). For example, let's say you have two repositories named fooproj and barproj, each laid out in a monolithic structure with the trunk, branches, and tags directories at the root of the repository. Now, let's say that as time has gone by, the two projects have converged to the point where you would like to be able to share code between them, so it would be nice to have them in a single repository. The following steps show how you could go about merging the two repositories by merging barproj into the fooproj repository. To start, you want to rename the repository to reflect its new multiproject status (make absolutely certain no one can access the repository while you do this; if you can't do that, use svnadmin hotcopy instead). $ mv /srv/fooproj /srv/foobar_repos
Because you're combining two projects into a single repository, it would make sense to move from a monolithic repository structure to a multiproject layout. That means that you want to continue by creating new project directories. $ svn mkdir file:///srv/foobar_repos/fooproj file:///srv/foobar_repos/barproj
Next, you need to move the fooproj directories into the newly created /fooproj project directory. $ svn mv file:///srv/foobar_repos/trunk file:///srv/foobar_repos/fooproj/trunk $ svn mv file:///srv/foobar_repos/branches file:///srv/foobar_repos/fooproj/branches $ svn mv file:///srv/foobar_repos/tags file:///srv/foobar_repos/fooproj/tags
After everything is moved around in your first repository, it's time to dump and load the second one. Because the svnadmin dump and svnadmin load commands output and input (respectively) the dump files on stdout and stdin, you can perform the whole dump/load cycle in a single command. To load the project into our newly created barproj project directory, we can also give a location in the repository for Subversion to use as a root for the loaded files. $ svnadmin dump file:///srv/barproj | svnadmin load file:///srv/foobar_repos
When Subversion loads a repository dump into an existing (populated) repository, it preserves the dates when the loaded repository's revisions were committed, but not the revision numbers. Instead, it adds each revision as a new revision in the existing repository, with revision numbers being incremented from a starting point of the existing repository's HEAD revision. For example, say you have two repositories; the first repository has 15 revisions numbered 115 and the second has 12 revisions numbered 112. If you dump the first repository and load it into the second repository, the revisions 115 will be added as revisions 1327 in the second repository. Splitting a Single Repository The converse to merging two repositories into one is to take a single repository and split it into two separate repositories. To illustrate, let's say that instead of two repositories named fooproj and barproj, you start with a single repository named foobar_repos that contains both projects (in root directories named fooproj and barproj, respectively). Now, let's say that those projects have grown extremely large, and your server no longer has the power to serve both projects. So, you decide that because the projects don't share much, it would be easiest to just split them into two different repositories and serve them from separate servers. The best way to accomplish a repository split is by using the tool svndumpfilter. With svndumpfilter, you can dump a repository and either include only paths that begin with a set of prefixes or exclude paths that begin with a set of prefixes. In our case, we want to create two repositories from two different root directories, so we'll run the dump filter twice and include only the project we want each time, as in the following example steps. 1. | Create two new (empty) repositories to hold each of the split repositories.
$ svnadmin create /srv/fooproj $ svnadmin create /srv/barproj
| 2. | Dump the original repository and run it through a filter that will only include the fooproj project directory. Then, load that into the newly created repository.
[View full width] $ svnadmin dump /srv/foobar_repos | svndumpfilter include --drop-empty-revs  --renumber-revs /fooproj | svnadmin load --ignore->uuid /srv/fooproj
Using the --drop-empty-revs and --renumber-revs options with svndumpfilter will cause the revisions of the newly created repository to be collapsed down, with any revisions that didn't include changes to the fooproj project removed. If the revision numbers are important to you, you can cause Subversion to leave them the same by leaving out those two options. The --ignore-uuid option is important, because Subversion will set the repository UUID to the UUID from the dump file if you are loading into an empty repository. You don't want your two newly create repositories to end up with the same UUID though, so --ignore-uuid will tell Subversion not to change the UUID. Because the UUIDs of the repositories will change, users of the repository will have to check out new working copies from the appropriate new repository.
| 3. | Repeat the dump and load to populate the barproj repository.
[View full width] $ svnadmin dump /srv/foobar_repos | svndumpfilter include --drop-empty-revs --renumber-revs /barproj | svnadmin load --ignore-uuid /srv/barproj
|
|
