Ok, so I had to write up a doc for my branching pattern for one of my clients. I thought this would be great to share with the rest of the world (if anyone is actually reading my blog).
——————————
The goal of this doc is to have a branching pattern process for SVN (and any other large project with 3+ developers), which is a web-based project based on Agile Development. This process is slightly different for software applications, because of release schedules and business requirements. Those usually fall into more of a waterfall approach. It should be important to note that this is not a science, but more of an art. If this approach doesn’t work, feel free to tweak and adjust it to make it work for your environment.
Trunk
Typically at the start of a project there really is no need to branch off the trunk since everything is just committed into the trunk. Every so often the code is exported and deployed out to the target site. Everyone interprets “Trunk” differently, but I recommend using it as the current production release. Why? It’s always the default set, and it gives you a good gauge of what the last stable release is. Some people use it as the latest code branch, which I hate doing because it’s not always stable.
ie:
— trunk
Tags
To keep track of what is released where, the standard practice is to create a tag directory and keep track of the releases in there. Typically people create a copy of the entire directory in there. I don’t think this is really necessary, except for branches. You can just create a shortcut or a text file in there, just to annotate where and when you did it. What’ you’ll typically see is show below:
Ie:
— trunk
— tags
—— 20090201-staging-trunk-r-32
—— 20090304-dev-trunk-r-42
—— 20090405-prod-trunk-r-56
—— 20090506-dev-branch-v-2.0-r-66
Note the naming convention:
[date]-[location]-[branch]-[revision number]
Branch
So now that we’ve got our first stable release out, and our tags in, our repo really looks like this:
— trunk
— tags
—— 20090429-dev-trunk-r32
—— 20090430-staging-trunk-r44
—— 20090501-prod-trunk-r56
Now, its time to branch. From past experience, there usually tends to be crazy requests, the need for quick bug fixes, or some fast (Agile) timelines. What I recommend doing here is branching into two new sets. By branching I mean copying the code directly into the branch directory. No links, no shortcuts, a full copy of the code into the branch directory,.
— trunk
— tags
—— 20090429-dev-trunk-r32
—— 20090430-staging-trunk-r44
—— 20090501-prod-trunk-r56
— branch
—— branch-v-2.0
—— branch-v-1.0
Branch v-2.0 (or whatever it is), is where all the new requirements should be coded and developed.
Branch-v.1.0 is where all the Bug fixes should be made. This is generally in sync with trunk when releases are made.
So at this very moment, we have 3 active code repos:
- trunk
- branch/branch-v.2.0
- branch/branch-v.1.0
MERGING
As we push out bug fixes, we MERGE the code into trunk, then we release trunk. At this point trunk and branch-v.1.0 are in sync. Here we should label the release as well.
— trunk
— tags
—— 20090429-dev-trunk-r32
—— 20090430-staging-trunk-r44
—— 20090501-prod-trunk-r56
—— 20090501-prod-trunk-r66
— branch
—— branch-v-2.0
—— branch-v-1.0
Always, always, always use the comments when merging your data sets. Otherwise it’s impossible to determine from the log when you did a merge. We can guess, but it’s easier to look in the logs to determine what happened.
It’s my preference to always merge the branch-v.1.0 into the branch-v2.0 so it doesn’t stray too far away from the bug fixes. Keep track of what revisions you’re merging in so that you don’t have conflicts when you’re doing a final merge. For more on merging google ‘svn merge process’. Remember comments are your best friend in SVN. Aside from comments, I sometimes create a text file telling me what code revisions are merged in.
QA Process and Code Merges
Once your branch-v.2.0 code is release ready and if you’ve been following my recommendations to merge in bug fixes regularly, you should have a production release copy in branch-v.2.0. At this point the QA process should kick off and there should be a freeze on new business requirements and features. Only QA fixes should go into this branch. Continue with production critical bug fixes on branch-v-1.0 and continuously merge into branch-v-2.0.
Once QA is complete, merge QA into trunk and release to staging, then to prod when complete.
Branch-v.2.0 is now your trunk and you can now start another branching process.
You should at this point have:
— trunk
— tags
—— 20090429-dev-trunk-r32
—— 20090430-staging-trunk-r44
—— 20090501-prod-trunk-r56
—— 20090501-staging-branch-v.2-0-r66
—— 20090601-prod-trunk-r77
— branch
—— branch-v-2.0 (deprecated)
—— branch-v-1.0 (deprecated)
