Branching Patterns / Policies

Question

I'm currently revamping the way our shop does version-control. We will be using a server centric version control solution.

I would like to see how other people are branching, and doing it successfully, without all of the headaches I read about.

What are some field tested branching patterns you have seen in a production environment that worked well i.e. branching per release. What policies have been put in place to ensure that branching goes smoothly.

Thanks

Answer 1

The subversion book describes some commonly used branching patterns (e.g. release branches, feature branches, etc.).

Answer 2

It depends on what kind of software you are developing.

For us, we are a web shop, so we do not have any numbered 'releases'. So, we keep the trunk as what is 'production' worthy and commit to that small changes.

When we have large projects we will create a branch and work those up all the while syncing trunk changes into it.

If the project is involves a large restructuring of the code base we will generally create a tag on the last revision before merging the branch changes.

Again, if you are creating packaged software where you need to maintain different versions this won't work as well.

For the record, we use Subversion.

Answer 3

This is the way we do and it works well for us...

Project
   |
   +--01-Development
   |  |
   |  +--Release1.0
   |  |  |
   |  |  +--Solution Files
   |  |   
   |  +--Release2.0
   |     |
   |     +--Solution Files
   |
   +--02-Integration
   |  |
   |  +--Release1.0
   |  |  |
   |  |  +--Solution Files
   |  |   
   |  +--Release2.0
   |     |
   |     +--Solution Files
   |
   +--03-Staging
   |
   +--04-Production

well you get the idea...

NOTE: This is the directory structure in Team Foundation Server Branches exist only between 01-Development/Release1.0 and 02-Integration/Release1.0, 02-Integration/Release1.0 and 03-Staging/Release1.0, 03-Staging/Release1.0 and 04-Production/Release1.0

In other words you wouldn't be able to merge 03-Staging/Release1.0 to 04-Production/Release2.0, etc...

What this does for us is we have 4 seperate environments Development, Integration (alpha server), Staging (beta server), Production.

Code starts in development starts in development and then gets promoted as it test by QA (integration/alpha) and users (Staging/beta) and finally to production.

Features/changes are collected and grouped into releases that occure every few months.

But lets say you are in development for Release2.0 and you get a production issue on Release1.0... I easily can get latest version of Release1.0 and fix the issue and promote it up without effecting anything that I have been working on for Release2.0

Not saying this will work for everyone in every situation but this works very well for us.

Answer 4

3 things when considering branching.

First : Branching is fine, as long as you intends to Merge things back later on. Sure you can always have a branch with a specific patch for one of your customer with a specific problem. But eventually you want to merge most of the patches back to the main trunk

Second : Assert your needs. I've seen tree of all sizes depending on the size of the department, the number of customers, etc...

Third : Check how good your source control is for branching AND merging. For example, CVS is notoriously very poor for this kind of operation. SVN, "CVS done right" as they claim, is somewhat better. But Linus Torvalds who created Git (which is especially good for this kind of operation) would tell you CVS can't be done right (he said it in a very interesting presentation on Git). So if you have real need for branching and merging, at least get SVN not CVS.

Answer 5

Have a look at branching patterns:

http://www.cmcrossroads.com/bradapp/acme/branching/

It describes a number of patterns for working with patterns. I've generally worked in two ways:

• Stable Receiving Line - all development is done in branches and merged into trunk only when required. This means you always have a single stable release point.

• Main Development Line - all work is carried out in trunk. When it comes to releasing you take a release tag and use that. If major experimental rework is required it's carried out in a branch and merged back into trunk when stable.