How can I re-merge a branch re-created from a trunk revision in SubVersion?

Question

I have the following architecture in my SVN repository:

/trunk
/branches/TESTING
/branches/STAGING
/branches/PRODUCTION

Here is my normal version control workflow:

1. Create a feature branches from the trunk.
2. Commit changes to the feature branches.
3. Once tested, merge the feature branches back into the trunk.
4. Delete the feature branches as they are merged/committed to the trunk.
5. Once ready for deployment, merge the trunk to /branches/PRODUCTION.
6. Deploy changes in /branches/PRODUCTION to the production system.

This workflow works great 99% of the time. However, a situation came up yesterday, and I'm having some trouble finding a work around.

Since the last production deployment, I had fixed a few bugs, and worked on several features, all of which were tested and then merged and committed to the trunk. One of those features was requested (by the client) to be deployed on the morning of June 17. Since the other features and bugs were not critical, I waited until June 17 to deploy them all together. Then on the afternoon of June 17, the client decided they wanted to back out the changes and wait until a later date.

Here's the steps I took:

1. Revert the trunk revision where the feature branch was merged (using Tortoise SVN "Revert changes from this revision" option).
2. Commit the reverse-merged revision to the trunk.
3. Merge the trunk to /branches/PRODUCTION.
4. Deploy changes in /branches/PRODUCTION to the production system.

This worked fine and the changes were easily backed out.

To prepare for the future deployment of those changes, I created a branch from the version of the trunk where the feature branch was merged.

However, when I tried to merged this new branch back to the trunk, none of the file changes are merged - the only update that occurs is that the trunk properties are updated.

This seems like a basic feature of version control - backing out changes and being able to re-merge them in the future - but I can't get it to work correctly. Is there another way to do this with SubVersion/TortoiseSVN?

Answer 1

You made a branch, made no changes at all, and then tried to merge that branch back in. That should always result in no changes! If branching ever resurrected old code that has since been deleted on trunk, it would cause all kinds of problems and nobody would ever use branches.

The easiest way to get your feature back, as Lazy Badger suggested in the comments, is to simply revert the revision which removed your branch changes in the first place.

If you want to keep with your current workflow instead, I suggest resurrecting your old deleted branch where the changes were made in the first place. Then merge that branch into trunk again. Alternatively, you could branch off your current trunk, and in THAT branch, revert the change that removed your feature changes. Then you should be able to merge your new branch into trunk.

Answer 2

I saw some errors, mistakes and misuses in your workflow

• You deleted merged branch. Why? Existing not touched anymore branch doesn't require more space, than it occupied at last revision in repo and deleting branch doesn't decrease side of repo. If you want compact|easy readable space under /branches node, you can use hashing tree instead of flat space (something like /branches/YEAR/MONTH/BRANCHNAME )
• Creating a branch from the version of the trunk where the feature branch was merged (without subsequent changes in this branch) is almost 0-value action:
  • If trunk's changes later will be in conflict with state of code in this revision, you'll have to perform manual resolving of conflicts anyway
  • When you merge two trees in SVN, changes in both trees from branchpoint take into account ( the real picture is more complicated, but this is a valid and correct simplification ), not the states of latest revisions in merged trees. Your "just copy" branch doesn't have changes inside, it brings nothing into merge-result
  • You can always re-merge HEAD of deleted branch again (it may require resolving conflicts, but I suppose, you'll have it in any case, remerging old branch give you just slight more amount )
• Branch with state of trunk with undo`ed feature is just useless, after all: if you want return back revision, which you undo by reverse-merging revision, at any time you can (have or must, probably) do it by reverse-merging of revision, which reverse-merge revision with feature (and repeat this process of reverse-merge of last reverse-merge any amount of time)