So I am using Subversion as SCM for a classic ASP webapp that I maintain. We use feature branching to handle changes that have dependencies or longer term development.
We use shared web servers for Dev/QA, and this is where my question comes in. The central Dev server is a working copy of trunk, and then when I need to see changes on Dev from a feature branch I merge them to the Dev working copy. So far so good, but am I setting myself up for ungoodness down the road?
For example, today an analyst told me I could “remove” the changes I had made to a feature and then merged to the Dev site for a demo–not because the feature was being killed, just because he didn’t need to see it anymore. And I realized I could not easily do that. The changes I merged now just show up as local modifications on the Dev working copy and I can’t easily peel them out (I’d have to manually revert changes to the affected files, since a full revert could/would kill changes related to other features).
The more I write about it the more I feel like I’ve answered my own question. Do I need to change my branching strategy–branch per environment? Or do I need to have a separate “shared Dev” site for each branch (dev.mysite.com:4801, dev.mysite.com:4802)? Or is this pretty much how you handle this?
If the feature you want to remove is exactly and entirely contained in one specific revision, on any branch related to your trunk, you should be able to do a reverse merge of that specific revision on the working copy of your trunk branch. Take a look on the options of the “svn merge” command. According to this page, you should be able to issue a command like this:
svn merge -c -Revision YourDevBranch YourWorkingCopy
This should remove one revision originaly commited to a branch, from your trunk working copy.
However if the issue is related to several features being commited in only one revision, even in the original development branch, then I guess the only choice is to remove the modifications manually.