I kept working in Trunk when I should have created a Branch for some major changes (Subversion, TortoiseSVN)

Question

I embarked on a set of major changes that touch a lot of different areas of the application, have required changes to the database schema, our objects and presentation code. I started at rev.1101 You could consider it a perfect case for creating a Branch to be later merged and integrated back into the Trunk once it was tested and complete.

But I didn't create a new Branch. I kept working on the Trunk instead.

The Trunk is now at rev.1116 and I'm in the unenviable (?) position that I have to perform some bugfixes on the revision about 15 versions ago which is the current release in production and then release bugfixed "rev.1101+bugfixes" to production without any of the work from revs 1102-1116.

Question: How do I "recover" the Trunk and move all the recent changes to a Branch? Do I create a Branch from what's in the Trunk right now and that becomes /Branches/MajorChangeSet, then revert the Trunk back to rev.1101, treat that as the now-official Trunk and start work on the bugfixes there?

UPDATE: I followed the procedure recommended by ChrisH below (according to the mockup above) and we're now in great shape. We have been continuing to update the "rev. 1102 production" with fixes and minor feature enhancements. These have been painless and easy to merge into the trunk to make sure that these changes also make it into our new development effort. Thanks all!

Branch v. Trunk | Branch/Tag/Trunk? | Branch when?

Answer 1

I recommend creating a release branch each time you start doing release candidates. Trunk stays live for work on things not going in the release (version .next as we say). The release branch is reserved only for bug fixes and stuff that must go in the release. It is good practice to always commit those to trunk first, then cherry pick merge them over to the release branch. Always try to merge FROM trunk into other branches because that keeps things easier. Reintegrating "feature branches" into trunk is fine, but fixing a bug in a release branch then merging it back into trunk should be avoided.

After a release is in the wild, the release branch is kept around for fixing additional bugs and eventually doing minor point releases. You should still fix the bugs in trunk first (no point shipping them in the .next release) and merging them to each release branch you are still actively maintaining.

The good news is you can start this methodology after the fact. Go back to the revision of trunk your current release was built from and create a release branch from that. TortoiseSVN has a handy menu for creating tags and branches from specific revisions when you right click on the revision in the log viewer.

Once you have your release branch you need to check it out and start merging over the bug fixes you want to release. All of your new work in trunk stays right where it is. If trunk and the release branch have diverged significantly then you might need to just make the fixes directly on the release branch, but try to make them in trunk and merge to the release branch when you can.

One more thing. Each time you ship a release from the release branch you should make a copy to tags with the version label of the release. It can be handy later to figure out what changed between releases or to rebuild an old release if you need to. We go as far as doing a complete build from the tag when we ship the release because we embed the SVN revision number in our product version so that if a customer reports a bug we know exactly what code they are running (since SVN revisions are unique across the repository).

Hope that helps, and good luck.