In Part III, you will learn the ins and outs of administering a Subversion repository. Mostly that means repository setup, because Subversion rarely requires much maintenance after the repository is up and running. In the simplest cases, even the front-end administration is trivial—simply create a new repository and add a few lines to your Apache config files to point them to the repository’s location. Conversely, for large, complex repositories, or repositories with many users, setup can get fairly involved. If you put in the effort to use hook scripts to automate integration and policy support, setup can provide a full-time job to one or more people for a decent period of time.
The ease of moving files and directories around in a Subversion repository means that it’s no longer necessary to spend countless hours arguing over exactly how the repository should be set up (knowing that changing it down the road will be practically impossible). Just because changing things is easy, though, doesn’t mean that you shouldn’t take the time to devise a good repository layout that will help support your project’s workflow. In fact, with Subversion’s flexible layout, you have a large number of options when laying out the repository, and a little thought into how to do so can go a long way. In this chapter, you will learn about many of the issues that you should consider when laying out your repository to support your overall workflow and to ease your project’s growth over time. You will also learn how to migrate an existing repository from a CVS or Visual SourceSafe repository.
9.1
Laying Out the Repository
Subversion gives you a lot of options for laying out a repository—or more to the point, it puts up very few roadblocks when you are laying out your repository. Your layout options are basically as unlimited as your options when laying out a regular filesystem. Addi- tionally, because branches and tags are handled as copies, you are free to organize your repository layout to reflect the types of branches and tags that you expect to make (for example, areleasesdirectory for release tags).
9.1.1
The Two Basic Layouts
There are two basic Subversion layouts. If you are putting together a simple Subversion repository, or don’t know exactly what the project structure and workflow is going to look
“svnbook” — 2005/4/14 — 14:55 — page 120 — #141
i i
120 Chapter 9 Organizing Your Repository
/
/trunk /branches /tags
Figure 9.1. A simple monolithic repository layout.
like, your best bet may be to just use one of these simple repository layouts. Of course, as the project grows, you can always move things around to improve the layout at a later date.
Monolithic Layout
The first layout is the basic monolithic project layout. In this layout, you have a single project in each repository, with a top-level directory for the trunk, as well as directories for branches and tags (see Figure 9.1). This is the better layout to choose if you have multiple projects that are unrelated (or only loosely related), in which case you can place each project in its own repository with a monolithic layout structure. It’s also the obvious choice if you are only tracking a single project.
The main project trunk will go into the trunkdirectory, whereas branches and tags will be copied into thebranchesandtagsdirectories, respectively. This allows a user to easily check out just thetrunkdirectory, and usesvn cpwith URLs to create branches and tags. Then, when the user wants to work on a branch (or use a tag), it is easy to use
svn switchto move the branch in to the checked out working copy oftrunk.
By keeping multiple projects separated in their own monolithically organized reposito- ries, you maintain the ability to relocate or back up individual repositories. That would, for example, allow you to maintain two heavily accessed repositories on different servers, or to archive the repository for a cancelled project off onto an offline storage medium to free up space on your active servers. Individual projects in separate projects also allow those projects to have their own revision numbers. If a modification is committed to projectfoo, projectbar’s head revision won’t increase by one.
If your projects are closely related, or are likely to share a lot of code, having each project in its own repository can be constraining. You lose the ability to copy or merge source from one project to another (while maintaining the history of the file in both projects), and you lose the ability to branch or tag both projects together. Also, because each project has its own independent revision numbers, it is hard to compare the state of two projects at an arbitrary point. However, if the projects are not closely related, but do reference each other, externals may allow you to share some commonalities between repositories without sacrificing the advantages of separate repositories.
9.1 Laying Out the Repository 121