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.