Subversion Best practices

http://svnbook.red-bean.com/en/1.5/svn-book.pdf

There are some standard, recommended ways to organize a repository. Most people create
a trunk directory to hold the “main line” of development, a branches directory to contain
branch copies, and a tags directory to contain tag copies. If a repository holds only
one project, often people create these top-level directories:
/trunk
/branches
/tags
If a repository contains multiple projects, admins typically index their layout by project (see
Branching and Merging
111
the section called “Planning Your Repository Organization” to read more about “project
roots”):
/paint/trunk
/paint/branches
/paint/tags
/calc/trunk
/calc/branches
/calc/tags
Of course, you're free to ignore these common layouts. You can create any sort of variation,
whatever works best for you or your team. Remember that whatever you choose, it's
not a permanent commitment. You can reorganize your repository at any time. Because
branches and tags are ordinary directories, the svn move command can move or rename
them however you wish. Switching from one layout to another is just a matter of issuing a
series of server-side moves; if you don't like the way things are organized in the repository,
just juggle the directories around.
Remember, though, that while moving directories may be easy to do, you need to be considerate
of your users as well. Your juggling can be disorienting to users with existing working
copies. If a user has a working copy of a particular repository directory, your svn move
operation might remove the path from the latest revision. When the user next runs svn update,
she will be told that her working copy represents a path that no longer exists, and the
user will be forced to svn switch to the new location.

Common Branching Patterns

There are many different uses for branching and svn merge, and this section describes

the most common.

Version control is most often used for software development, so here's a quick peek at two

of the most common branching/merging patterns used by teams of programmers. If you're

not using Subversion for software development, feel free to skip this section. If you're a

software developer using version control for the first time, pay close attention, as these patterns

are often considered best practices by experienced folk. These processes aren't specific

to Subversion; they're applicable to any version control system. Still, it may help to see

them described in Subversion terms.

Release Branches

Most software has a typical life cycle: code, test, release, repeat. There are two problems

with this process. First, developers need to keep writing new features while quality assurance

teams take time to test supposedly stable versions of the software. New work cannot

halt while the software is tested. Second, the team almost always needs to support older,

released versions of software; if a bug is discovered in the latest code, it most likely exists

in released versions as well, and customers will want to get that bug fix without having to

wait for a major new release.

Here's where version control can help. The typical procedure looks like this:

1. Developers commit all new work to the trunk. Day-to-day changes are committed to /
trunk: new features, bug fixes, and so on.
2. The trunk is copied to a “release” branch. When the team thinks the software is ready
for release (say, a 1.0 release), /trunk might be copied to /branches/1.0.
3. Teams continue to work in parallel. One team begins rigorous testing of the release
branch, while another team continues new work (say, for version 2.0) on /trunk. If
bugs are discovered in either location, fixes are ported back and forth as necessary. At
some point, however, even that process stops. The branch is “frozen” for final testing
right before a release.
4. The branch is tagged and released. When testing is complete, /branches/1.0 is
copied to /tags/1.0.0 as a reference snapshot. The tag is packaged and released to
customers.
5. The branch is maintained over time. While work continues on /trunk for version 2.0,
Branching and Merging
113
bug fixes continue to be ported from /trunk to /branches/1.0. When enough bug
fixes have accumulated, management may decide to do a 1.0.1 release: /
branches/1.0 is copied to /tags/1.0.1, and the tag is packaged and released.
This entire process repeats as the software matures: when the 2.0 work is complete, a new
2.0 release branch is created, tested, tagged, and eventually released. After some years,
the repository ends up with a number of release branches in “maintenance” mode, and a
number of tags representing final shipped versions.