Recently I committed a number of changes to include a critical feature on a branch (that was to be tested and released soon). Almost immediately after finishing, I was informed that the feature would be slipped to the following release because of testing time constraints. It was disappointing that my extra work would not be seen as quickly, but understandable: this is the world we live in and we have an obligation to our customers to release responsibly. But I digress.
We quickly faced the problem: how do we remove all of my changes from the branch so it doesn’t go out in the next release? Other people had committed changes to the same files, and our commit history was intermingled.
It’s easy enough to merge the branch to the trunk. But to remove the changes from the branch requires a little thought. Subversion has full documentation on merging, and on cherrypicking (which is what we want in this case). But it’s easier to just see an example.
Let’s say I’ve committed revisions 123, 134, and 137. I later find out that I need to remove these changes completely. We need the latest revision of the code to look like these changes were never made.
svn merge -c-123 -c-134 -c-137
This modifies my working copy as if I had gone in and removed the changes manually. My local files are modified, and on the next commit the changes from those revisions will be removed! Of course the changes and the undoing of the changes still exist in the commit history, but the revision at the head does not contain the changes, and in our scenario the feature will not go out in that branch.