Subversion Branch/Trunk Best Practice - keeping Branch Up-to-Date?

So assuming I've got your model right here: You develop major changes to the project in a branch (off of trunk) which can get quite old.

You continue to do other development on trunk which always holds the 'live' software, so these changes are minor updates and bug fixes. You're getting problems when you merge the monumental development branch back into trunk.

You can only effectively manage 2 concurrent product versions with that model, which may be enough for now, but might bite you in other ways anyway and will get worse if you ever need to manage 3 or 4 versions. Can I suggest inverting the way you work?

Have a Version branch for each release. This should be branched from trunk (at any revision). The only way you modify the version branch is to merge in revisions from trunk.

This means you can work primarily on trunk instead of in a large development branch. You also apply your bug fixes directly to trunk - so you've got no major integration issues being stored up for the next release. To release bug fixes to the previous versions, just merge the required trunk revisions into the appropriate Version branch.

This way you can keep everything you want to release in branch, but only actually ever release what you're happy with, because that's all you merge in to the version branch.

You can still take development branches if you need, but you can keep them targetted and small, perhaps individual features rather than large projects.

This will allow you to manage multiple versions in a sane way and keep a good track of what's in each release using svn's merge-info.

Our experience is to clearly differentiate:

• development branch
• consolidation branch (branch used to consolidate development we are sure to go into production

Trunk is only for recording stable released version, from which we can branch.

In the "development branch", we can manage important changes, included some which will not end up in the next release (because too complex, not ready in time, dependent on other late developments, ...)

The consolidation branch represents the final steps (note the plural) needed to finalize the release. It happens after a meeting where all the features needed to be delivered are validated.

We only merge into the "consolidation branch" what we are sure to put into production. We go on that branch until the final release.

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.