I’m trying to develop a workflow which allows us to maintain seperate Visual studio 2005 and 2008 versions of a library, while making sure that changes to one branch are always replicated in the other branch.
At the moment, I recommend that changes are only ever made to the default (VS2005) branch and then once complete, merged into the VS2008 branch. Unfortunately this relies on the discipline not to just fix problems as and when they are found and when you are in a crunch, that can be difficult. This has resulted in me having to attempt to retrofit changes from one branch back into the default at a later date.
I know that we could store the changes between the VS2005 and VS2008 project in a patch queue, but I’m the only one in my team who is comfortable with using the command line, my colleagues prefer to do everything though Tortoise HG.
As such, I rely on fixing up problems after the fact. My current procedure involves exporting patches for every changeset in the VS2008 branch and applying them to the default branch. This is time consuming, but much less error prone than trying to merge the tip of the VS2008 branch with the tip of default, and then hand converting back to VS2005 by hand.
Having read this article, I tried backing out the ‘upgrade’ changeset, but the resulting backout changeset always ends up as the new tip of the VS2008 branch, plus I can’t then merge the changes back in, since the resulting merge ends up in the VS2008 branch, even if I attempt to explicitly close the branch on commit.
I’ve tried going at this in a number of ways, but I always end up with a new VS2008 branch tip and no way to merge the changes back into the default branch. As such, I’m starting to thing that I’ve missed something obvious here.
So, ultimately, what do other people feel is best practice when trying to maintain two versions of a library where the only difference you want between the two are Visual Studio version numbers, embedded into the project and solution files?
Edit: The problem that I’m trying to avoid is that if you add a VS2005 project to a VS2008 solution (for easier debugging) it automatically ‘upgrades’ the VS2005 project to VS2008, resulting in a ‘changed’ working copy and a spattering of unecessary ‘conversion’ files. So, rather than people being tempted to commit their ‘upgrade’ to the mainline, I prefer to keep the branches seperate and require the user to pick the version they need on the first update after the clone.
Further edit, with solution.
With some more messing about, I found a way to make this workflow work with standard TortoiseHg tools, and command line intervention only needed to set things up.
Firstly, I updated back to the changeset in which the project was converted from VS2005 to VS2008. I backed out that revision, created a patch of the backout and stripped the backed out changeset (since it was in the default branch). Then I applied the backout patch to the conversion changeset (using: hg patch –no-commit patch) and then comitted the patch with a new “VS2005” branch name. I then merged in the tip of the (unnamed) VS2005 branch.
The next step was to update to the old tip of the (unamed) VS2008 branch, make an inconsequential change and commit it as a new “VS2008” branch. I then merged in the changes from the VS2005 tip, but when I comitted did not allow the changes to the csproj files to be comitted. I then reverted these files after the commit.
Finally, I updated to the VS2005 tip and merged in the VS2008 tip.
This resulted in two tips, both with identical code, except for the differences due to the VS2005 to VS2008 conversion.
New workflow:
- Work in either VS2005 or VS2008 branch, as required.
- Once updates are done in one branch, update to the other branch, merge the changes from the modified branch in and commit to it’s own branch. Then update back to your preferred branch.
- If updates occur in both branches simultaneously, do both branches seperately, i.e,. update to the VS2005 tip and merge in the VS2008 tip, then update to the VS2008 tip and merge in the previous (pre-merge) VS2005 tip.
It seems a little odd to answer my own question, but without doing this I can’t indicate to StackOverflow that this question has an accepted answer.
For full details, see my question – after the horizontal rule.
I should add my thanks for everyone elses answers though. I may still find a use for premake, and seperate project/solution files could work in other situations. One day I will undoubtedly find a use for Mercurial Queues myself, but I doubt I will ever get the rest of my development team to use them. I’ve never been comfortable with hard links on Windows, so I probably won’t ever try that, but it’s good to be reminded of their existance.
Take care & thanks again to everyone who took the time to respond.