views:

205

answers:

5

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.
+1  A: 

We use separate solution and project files. We copy the .sln and .csproj/.vcproj/.vbproj and edit them in notepad to use the new files. You still have to remember to add a file to the other solution when adding classes, but otherwise you don't have to remember to copy over the fixes.

Joel Lucsy
+1  A: 

The Mercurial: The Definitive Guide book has a whole chapter on using Mercurial Patch Queues to maintain backports for older Linux Kernels. I think the mq extension could help you out.

John Paulett
As I said, while I'd be happy to use MQ myself, persuading the rest of my group to use them would be tricky. If I can't get them to follow the procedure of 'only ever fix in default, then merge into VS2008', I can't see how I can get them to buy into messing around with pushing and pulling patch queues. What I really need is an easier way to fix problem (with forgetting the procedure) after the fact.
Mark Booth
+1  A: 

Instead of solving the problem you could try to make it go away: try premake.

Premake is pre-build system (as the name implies it is intended to run pre-make or pre-MSBuild if you will). You describe your project once in a declarative internal DSL built on top of the Lua scripting language and premake can automatically generate solutions and projects for VS2008, 2005, 2003 and 2002, MonoDevelop, SharpDevelop, Code::Blocks, CodeLite or a GNU Makefile for either Unix, Cygwin or MinGW. It currently supports building C++, C and C# projects, including cross-compiling for 32/64 Bit, OSX Universal Binaries, PlayStation 3 and XBox 360.

The configuration language is very clean and declarative. However, being built as an internal DSL on top of Lua, you also have the full support of a very powerful, beautiful, expressive (and most importantly Turing-complete) scripting language at your fingertips. Both the structure and the terminology of the configuration language are directly based on Visual Studio: it talks about solutions, projects, configurations and platforms.

The premake tool itself is distributed as just a single .exe which includes the Lua interpreter, Lua standard library and of course the premake script itself. It has absolutely no external dependencies, does not write a configuration file nor writes or even just reads the registry.

All you need to do is to translate the VS2008 solution into premake once by hand.

Jörg W Mittag
This looks great, but it seems to lack a few features, and patches from May have not been brought into the build. It looks to have stagnated.
polyglot
The last commit to the source code repository was 46 hours ago, the beta releases for the upcoming 4.2 release (adding support for the XCode IDE and building Objective-C and Objective-C++) were 20 and 25 days ago, the three releases (so far) of the current stable 4.1 release were 3, 5, and 6 months ago, the last time someone asked a question on the forums was two weeks ago and the author himself responded within minutes. The last post of the author to the forums was yesterday. So, it doesn't look that stagnated to me.
Jörg W Mittag
On the off-chance someone finds this thread while looking for Premake info: we pushed off those patches because they are big and need additional work, while Xcode support had to get out the door. I think our track record overall has been pretty darn good. No offense taken though, just wanted to clear the record.
starkos
A: 

Perhaps you should not maintain two different branches, but only one containing the source code and the Visual Studio 2005 project files. The second branch should only contain the Visual Studio 2008 project files, not the source code again. To get the Visual Studio 2008 version compiled, create hard links on your local drive for all source files to make them appear in both folder trees (put the hard link creation in a batch file together with the commands for getting the latest updates from the repository). For this approach you need NTFS file system and an appropriate "ln" command line tool, for example this one.

So you can debug/edit your source code in either folder you want, all changes immediately appear in the other folder, too.

Edit: and yes, I have tried that by myself, it works. We have a very similar scenario, having a C++ application to be compiled with Visual Studio 2008 and an older Borland compiler.

Doc Brown
A: 

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.

Mark Booth