Best process for "back-porting" changes to prior release

Steve Endow
Steve Endow used Ask the Experts™
I use VisualSVN with Visual Studio.  VisualSVN is working great, but I don't know how to best use some of the version control features.  I almost never need to revert to prior versions, and therefore use very few of the VisualSVN features.

This is the issue I am facing at the moment.

Version 1 is stable and in production.

I start work on Version 2, making numerous changes (new features) to the code and producing a V2 release that is deployed to the Test environment.  My version 2 code has been Committed to VisualSVN.

The customer then identifies an issue with Version 1.  I need to identify the issue and fix it.  The customer wants the change made to Version 1 so that it can be deployed to the Test environment for a fast-track testing and deployment to production.  And the fixes need to be made in Version 2 as well.

To get through this issue, I initially made the changes to Version 2 for expediency and tested them to verify that I resolved the issue.  But now I need to "back-port" the changes to Version 1, for which I don't have a good process.  I pulled down a copy of V1 into a separate directly, and I'm now having to review all of the Diffs between V1 and V2, find the ones that relate to the bug fix, and apply the fixes to V1 so I can create a new V1.1 build, which I won't ever Commit to VisualSVN.

I am assuming this process I am using is not the proper method.  

I have two questions:

1. Is there a term to describe this scenario? (releasing a fix to a prior release)

2. What is the textbook approach for dealing with changes to a prior production release while changes are underway for a new release using VisualSVN?  

I'd prefer responses that are specific to VisualSVN for Windows that only involve the GUI.  But I'm also open to info on the general process to best handle this scenario.
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
You havent explained whether you branched the codebase for V2 or not but I do expect that to be the case. Say you have two branches


then you can merge changes from one branch to another. And this is a fairly well known scenario.

You'll find a lot of articles if you search for "merging branches in SVN" and I hope some of those might actually help your exact situation.

In practice, however, I think things are not as easy or straight forward as described in such treatises. I have been through the exact same scenario and I had to actually suffer the process of manually reviewing every little detail and applying them on the other branch. In the process I figured out some mistakes I had made and how I could have avoided. It all boils down to using SVN in a disciplined manner (all team members) - often neglected and even more difficult to have every team member appreciate it.

1 - Changes should ideally be committed to SVN in atomic fashion (all at once) and as small as possible. NEVER, ever, commit changes that span across two distinct bug-fixes or features (unless there's an absolute dependency). This allows you to selectively merge only a specific revision across branches, e.g.

Obviously, this too becomes a problem sometimes, especially when a lot of refactoring is done prior to a fix, which leads to point# 3.

1B - Say no to Adhoc commits, commits made just to be able to checkin on you home machine and be able to check it out on the server. Get a private branch if you cant live without it.

2 - Be prepared to rollback commits and re-commit as an atomic commit. Sometimes you think you had it fixed and commit it just to find out having to fix it "more." In this case, I prefer to keep the commit all inclusive. In a team env, this becomes problematic and therefore in our env, I have always voted for every member to keep a separate branch and pay respect to the "master" branch.

3 - Bug fix the release/active branch even if that means you have to re-fix it in the new/dev branch. Make sure fixes are always checked-in atomically. You can always merge upwards if your fix is simple. For example. in my scenario I had massively refactored the design for new version and then fixed a few things - that simply didn't make sense to merge backwards because of the dependency on new design artifacts that didnt even exist.

I'm sure there might be other good ways to manage such scenarios and I would love to embrace one that is easiest to adopt.
ste5anSenior Developer
It depends on your folder layout (branches, tags, trunk) and your tools. I don't have VisualSVN installed so I cannot tell whether it supports it natively.

Btw, normally you would fix it in V1 and port it to V2. So I don't know whether a back-port works.

TortoiseMerge (part of TortoiseSVN a Windows Explorer integrated SVN GUI) supports this kind of merge.

Maybe you should also read about Cherrypicking in SVN as well.


Hi @ambience and @ste5an,

Thank you very much for the feedback.  Very helpful.

To address the points that @ambiance made:

1. I am not using Branches, which is probably a significant part of my problem.  Once you explained it, it seemed obvious, but previously I had never thought about it or bothered to use that feature.  I need to look into the Branches functionality and see how to use it to manage different releases.  I've been using VisualSVN for a few years now, but so far have only worked on the trunk code.  (I'm the only person working on my code, so there isn't a lot to manage.)

2. I have primarily been using VisualSVN as a glorified backup code repository. Since I'm an independent developer, and since most of my projects are relatively straightforward with no need for advanced source control features, I haven't really needed to learn any of the features...until this recent episode.

3. Related to #2, I've been checking in code to back it up rather than to commit specific / discrete changes.  This obviously can make things a little messy if I have multiple commits that don't relate to specific changes or milestones in the code.  When I implemented VisualSVN, my primary concern was backing up my code in a central location, and VisualSVN has done that well.  But I think I now need to develop some discipline around version control and branch management.


VisualSVN uses TortoiseSVN, so I think I need to invest a few weekends reviewing both solutions and learning more about their features.

The one issue I've found with VisualSVN is that much of the documentation is lifted from the command line SVN, so it's often difficult to figure out how to utilize the SVN features via the VisualSVN and TortoiseSVN UI.  It took me several minutes to figure out how to find a list of revisions and do a diff in Visual Studio since the process and UI is completely unintuitive.

Thank you both for the feedback.  I now have a new project on my list.




Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial