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.

Answer 2

One approach is to create a branch for each major release, onto which you can apply bug fixes independently of any work going on in trunk.

To create the branch retrospectively, try:

svn copy http://svn/path/to/trunk@1101 \
         http://svn/path/to/branches/last_monday_release

@1101 is a peg revision - essentially we're saying "figure out what trunk referred to in revision 1101, then copy that to make a branch".

(the SVN book has a scary explanation of peg revisions, if you're feeling brave)

Answer 3

Well, it's a bit of a mess no matter which way you look at it, but you also haven't done anything overtly wrong. You've simply continued developing in your trunk - which is correct - but now you need to go back to a previous revision and add some of the changes then re-release.

The problem seems like you have a series of revisions with both bug fixes and new features and you're just trying to take the bugs since a certain point in time and ignore everything else. It would be a little easier if the bug fixes were in discrete revisions (at least for identification purposes), but often they tend to accompany other changes.

Two options:

1. Take a branch of the last revision which you released then manually move over your bug fixes.
2. Take a branch of the last revision which had a bug fix then remove the new features.

Depending on the balance between new features and bug fixes, one of these will likely be easier than the other. Either way, you want to end up with a branch just especially for this release.

Answer 4

One way to fix this is to

• make a working branch from HEAD of trunk
• delete trunk
• recreate trunk from the trunk revision prior to your accidental changes

This way you will not see the accidental commits and reversions in log/blame on trunk. But be aware when updating working copies - I'm not sure how well svn update handles deletion and recreation of a repository location.