When we started two years ago, we had a simple rule: everyone commits to trunk. It worked while we were five people. Now we have six developers, three parallel projects and a client who needs a hotfix on the version in production.
Our branching strategy¶
After several months of experimentation we settled on a model: trunk/ for main development, branches/release-X.Y/ at feature freeze, branches/hotfix-X.Y.Z/ for urgent fixes and tags/release-X.Y.Z/ as immutable snapshots. We don’t use feature branches — merging in SVN is painful.
Release process¶
Two months of development in trunk, then a feature freeze and creation of a release branch. Only bugs are fixed in the release branch. Trunk is opened for the next development cycle.
Hotfix workflow¶
The client calls on Friday at 4 PM. The production version is 2.0.3, trunk is at 2.1-SNAPSHOT. Create a hotfix branch from the last release tag, fix, test, deploy, merge back. Never fix directly in a tag.
SVN hooks and access rights¶
A pre-commit hook requires a JIRA ticket number in the commit message and prevents commits to tags/. Post-commit notifies Hudson. The authz file restricts write access to release branches to senior developers.
Conclusion¶
SVN branching is not a nightmare with clear rules. When we move to Git it will be for better merging, not because SVN doesn’t work.
Need help with implementation?
Our experts can help with design, implementation, and operations. From architecture to production.
Contact us