Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win


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

Posted on 2015-01-22
Medium Priority
Last Modified: 2015-01-23
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.
Question by:Steve Endow
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
LVL 22

Accepted Solution

ambience earned 1600 total points
ID: 40566075
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. https://www.visualsvn.com/support/svnbook/branchmerge/basicmerging/

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.
LVL 35

Assisted Solution

ste5an earned 400 total points
ID: 40566091
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.
LVL 18

Author Comment

by:Steve Endow
ID: 40566795
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.

LVL 18

Author Closing Comment

by:Steve Endow
ID: 40566796

Featured Post

Efficient way to get backups off site to Azure

This user guide provides instructions on how to deploy and configure both a StoneFly Scale Out NAS Enterprise Cloud Drive virtual machine and Veeam Cloud Connect in the Microsoft Azure Cloud.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

It seems a simple enough task, yet I see repeated questions asking how to do it: how to pass data between two forms. In this article, I will show you the different mechanisms available for you to do just that. This article is directed towards the .N…
For those of you who don't follow the news, or just happen to live under rocks, Microsoft Research released a beta SDK (http://www.microsoft.com/en-us/download/details.aspx?id=27876) for the Xbox 360 Kinect. If you don't know what a Kinect is (http:…
Are you ready to place your question in front of subject-matter experts for more timely responses? With the release of Priority Question, Premium Members, Team Accounts and Qualified Experts can now identify the emergent level of their issue, signal…
Despite its rising prevalence in the business world, "the cloud" is still misunderstood. Some companies still believe common misconceptions about lack of security in cloud solutions and many misuses of cloud storage options still occur every day. …

610 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question