Subversion Best Practices for Web Applications

8/2/2019 Subversion Best Practices for Web Applications

1/6

Subversion Best Practices for Web

Applications

A few months back I had some dialogue with Nick Parker from uship.com. He was

wrestling with getting version control setup in a way that would meet the needs of

his team and wanted to brainstorm a bit. Here is a portion of our discussion that

speaks directly to a couple of the problems Nick was trying to solve:

Im trying to figure out the best way to set up our subversion repository to do a

couple things:

1. Facilitate peer code review.2.Always have an "uploadable" version of our website (i.e. - be able to

decide exactly which parts of the code go up when).

These questions and the context of Nicks situation really interested me. I think that

most if not all software development teams have to answer hard questions about

version control at one point or another. And if not at the start of a project then after

learning a hard lesson from not using version control appropriately.

In addition, you will notice from these questions that Nick isnt letting the tool

(subversion in this case) shape the goals for his team or the desired process.

Instead, he has a clear direction in mind, he has some specific pieces of the

development process that are proven and valuable, and he wants to use the tool in a

way that would enable his chosen approach.

Like I told Nick, although I dont have the perfect solution to these issues, I can

share an approach I like to use on projects that has worked well and should provide

a good foundation.

(Note that this approach was born out of a need to simplify and increase consistency

of deployments to the asp.net suite of sites. Our team was switching from Vault to

Subversion at the time and really needed a better approach for managing

environments independently and deploying more automatically.)

DIRECTORY STRUCTURE

This is probably one of the most overlooked pieces of setting up a Subversion

repository for new users. Its easy to just start a project and begin checking in files


2/6

as needed. And with some version control systems this isnt a big deal but with

Subversion I think its really important to start with a structure that sets the flow of

your development process.

Here's a snapshot of they way I typically setup the directory structure for a

Subversion (SVN) repository and is loosely based on the Branch-When-Needed

system described in SVN Best Practices:

Trunk is where all the day-to-day development happens. It includes everything you

want to version control on a project. And it should at least include a single directory

for the web application. The web directory should contain the application as it is tobe deployed compiled binaries and all.

As the name implies, Branches is used to keep track of the branches for your web

application. In order to have independent version control of your web application

per environment you should have a branch of the trunk/web folder per

environment. And they should be branched in the order of deployment. For

example, the alpha branch should be branched from trunk, while the beta branch

should be branched from the alpha branch.

Tags is used to keep track of specific versions of a branch or deployment

milestone. Because each environment specific branch has its own change log, you

probably don't need to tag each time you do a deployment to each, but it is a good

idea to tag major versions and deployments to production.

DAY-TO-DAY DEVELOPMENT

So, how does this apply specifically to Nicks questions and the day-to-daydevelopment process?
http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.htmlhttp://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html


3/6

1. Facilitate peer code review.

You can use Trunk to do peer code review. It is where developers always check in

their code. If you are using continuous integration (Nick mentioned that his team is

using CruiseControl) your build tool can pick up the check-in to auto-build and keep

everyone honest. Every check-in can be compared to previous versions to see what

changes were made and revert if necessary. This is a natural aid in the code review

process.

DEPLOYMENT

2. Always have an "uploadable" version of our website (i.e. - be able to decide

exactly which parts of the code go up when).

The branches provide exactly this. You only merge into alpha what you want

deployed to alpha (or staging) and you only merge into beta from alpha what you

want deployed to beta. This kills two birds with one stone. First, you have complete

control over what changes are deployed to which environment. Second, you always

know the code that is running in each environment.

To simplify deployment and remove human error, you can set up command line SVN

and create a simple batch file to do an svn update on the server. Then deployment

becomes as easy as merge changes, update server. Or, if you use CruseControl you

can automate the build and deployment on checkin for a specific environment.

FEEDBACK

Now, there are obviously a lot of sophisticated ways to change this approach and

make it work better for different development processes. Understand, that the

above is meant to be a simple example of an approach that solves many of the basicproblems that teams encounter with using version control to fit their process and

workflow.

I am quite interested in how you use version control to solve these problems on your

development team. Whether you use Subversion or another tool please share your

approach and any feedback you have on the approach described above.

And Nick, if youve had a chance to experiment more please share what approach

you ended up using.


4/6

SVN Best PracticesThis section outlines some of the best practices in how your repositories should be structured.

There are three main sections repositories usually follow and they are called the trunk, tags, and

branches. You are completely free to structure your repository in anyway you see fit, however

these are the more common industry standards and terminology in use and it is generally a good

idea to follow and be familiar with them.

Multiple repositories and projects.

The base of your repository should typically reflect the different projects you are working on but I

find it is really dependent on complexity. For my personal repositories where I have multiple small

projects going on at a time, I may set up multiple roots like so:www.duchnik.com

/trunk

/tags

/branches

www.pixanova.com

/trunk

/tags

/branches

However in a company environment where you have much larger projects and many brands its

usually a good idea to create separate repositories for each major project. You will however see

this implemented in different ways, where a particular brand within a company may have multiple

sub folders representing different portions of each brand or products.

Repository 1 (duchnik.com):www.duchnik.com

/trunk/tags

/branches

DownloadManager

/trunk

/tags

/branches

Repository 2 (websanova):www.websanova.com

/trunk/tags

/branches

platform.websanova.com

/trunk

/tags

/branches

However many repositories you create or however many projects you decide to setup per

repository the key is to always make sure that you have the trunk/tags/branches structure within

each project.

Trunk

The trunk is where the core of your work will happen and it represents the most current version of

your code even if it contains bugs. You will typically develop your features in the trunk and then

commit them once they are complete into the central repository. When you're working on a new

version of your code, you will typically get your trunk to a state where its ready to be versioned off

as the next latest and greatest version of your code. Sometimes though, you will see the trunk

versioned off even if there is no official release, and it is ratehr to jut take a snap shot of the

codebase at that current state, maybe for branching or split testing.

Tags

Tags are where you will be maintaing all the versions of your code. I find the most basic structure

is a three number versioning system, where the first two numbers are an external representation


5/6

of the version of that code, while the third number is more of an internal representation just

representing bug fixes. So for example, lets say you being your project and you release your first

version and you tagged it as "version_1.0.0".www.duchnik.com

/trunk

/tags/version_1.0.0

At this point typically your trunk and version_1.0.0 will be exact copies of eachother. Now you

continue developing and adding new features, you eventually decide you want to release a new

version which includes some awesome new features. You then would tag it again, but this time

increment the version number like so:www.duchnik.com

/trunk

/tags

/version_1.0.0

/version_1.1.0

You will then get to a point where, you want to completely revamp or upgrade your application in a

way that breaks from the current version line. There is no hard rule for this and is really just based

on how you feel your application is evolving, but you may make a major version update like so:www.duchnik.com

/trunk

/tags

/version_1.0.0

/version_1.1.0

/version_2.0.0

You can continue to add versions in this fashion, allowing you to keep a clean history of each

version you have ever released. What happens is next is that you may find a bug in your code and

you will want to fix it and merge it back in. There are a few ways to do this, the most common is

usually to just go into that tag and fix that bug then increment the version number, however, you

can also make a copy in your branch, fix the bug there and merge those changes up through the

different versions. However merging in SVN can be a pain sometimes and in smaller environments

you will usually see the former approach used. However you decide to get your bug fix into each

version that needs it, at this point you will increment that final version number. This again can be

done in different ways, with some people preferring to just rename the current folder to that latest

version and others preferring to create a completely. I typically prefer to rename the folder as I

dont really care about the previous version with the bug, I just want the latest most bug free

version.www.duchnik.com

/trunk

/tags

/version_1.0.0

/version_1.1.0

/version_2.0.1

Branches

Branches are typically used to fix bugs and to develop features outside of the trunk. Sometimesyou will be doing your regular everyday development in the trunk and you will get a request to add

some feature or fix a bug. The problem is you can't just update to another version of the code in


6/6

your trunk because you will lose your current code and you don't want to commit the code you

currently have because its not finished yet. The trick is to make a copy from one of the versions

under tags, and copy into branches with a name like "feature_4_download-manager". From there

you can develop the feature independently and then merge into any other tags and into the trunk

later on. This allows you to have a clean version of that code containing only that feature or bug,

which you can then decide what other versions should include it.www.duchnik.com

/trunk

/tags

/branches

/feature_4_download-manager

/feature_7_icon-gallery

/bug_46_invalid-character

From the above example you can see how this might be structured with multiple features. I've also

showed a bug here too and this follows the same ideas as adding a new feature. In most cases you

will also see a number associated with the path, which usually represents a case or bug number inwhatever project management application you are using. This gives you the number which you can

look up directly and find out exactly what that bug or feature is supposed to fix or add. The small

two to three word description is there just as a quick reference.

Documents

Subversion Best Practices for Web Applications