My development team has worked with subversion for quite some time. The way that manage the trunk and branches is as follows:
-
We (almost) always release from the trunk
-
Each release gets its own branch.
-
When a release is ready for QA, we merge the branch back into the trunk and create a new branch for the next release.
-
Developers work off of either the trunk or the branch, but there are no developer-specific branches.
Lately, we have had some nightmare merging sessions, in part due to some major changes to the application. These don’t always go smoothly and issues sometimes pop-up during QA where subversion did not merge quite right.
One solution might be to merge trunk changes into the release branch on a regular basis, say weekly, to ensure that the most up-to-date trunk changes are in the branch. Conflicts can then be fixed in closer to real-time.
What is your experience with this issue? Is there a standard best practice? Also, do you have a good way of keeping track of which revisions have been merged into the branch (decent comments in subversion could probably handle that).
Firstly, I don’t think there’s a one-size fits all solution when it comes to managing code branches and releases. But to touch on a few of your points from my perspective:
Yes, I would merge changes from trunk into the release branch more often. Smaller chunks are always going to be more manageable than one large integration. And of course this means you’re working against the latest most stable code.
Proactively teach people how to merge well. The developer who made the change should be doing (or be closely involved with) the merge. Understand what it is you are taking and what it should look like when it is finished. I too often see people run a integration without really knowing what they are doing and what they are expecting as the result.
Perhaps you want to have an integration branch that isn’t trunk. This can be tested daily and any issues caught here before they go and break trunk and scare everybody.