Friday, April 11, 2008


Yesterday at work, for the first time in 8 years of using Visual Source Safe, I was confronted with the real prospect of having to attempt to branch a set of Visual Studio .NET projects. Up until now, I have managed to avoid the need, I'm not sure how.

After some lengthy discussions with the development team, I created a Sandbox VSS database and imported a set of VS2005 projects that make of a single solution. I created a VSS directory to contain branches, set up the hierarchy and executed a "Share and Branch" operation for each project in the solution into the branch directory. This worked fine.

We then started looking at the merge functionality. I knew all of this existed but had never used it except for once many years ago when the team I was on tried using the "multiple checkout" mode of VSS (we switched back to exclusive checkout not long after). Our main discovery was that you must merge every file individually. This isn't to say that you have to merge them manually however. While we didn't encounter it this time in the test, my recollection is that VSS will merge automatically unless there is a conflict, then you get the diff/merge dialog to decide what goes. The important point is that there doesn't seem to be a way to merge an entire VSS directory back to it's initial branch in the tree (lacking the "trunk" terminology in VSS). You must initiate each merge operation on each file manually. With 10s of projects in a solution, dozens of changed files and 100s of coexisting files, it is not viable to manually merge every file. It would be faster to use Floppy/Sneaker Net.

So I'm becoming more and more convinced that we are closing in on the end of VSS in our organization. I've been using SVN (Tortoise & Ankh) a bit lately and it seems to work pretty well. SVN certainly has far better branching support.

One of my concerns with any SCM system is how to execute branches within the context of visual studio solutions. If I branch one or more projects then the solution file will need to change, or more practically we'll just create another one for the branch. But then the project files change as well as the physical location of projects change which needs to be reflected in the project references. Then, after completing work on a branch when a project file is merged back into the trunk you have to take care to merge project references back to their proper state.

In addition to all of this, the build system we have been using may encounter issues because of the way the build is executed. However, if the branched project files are committed correctly then it should behave correctly.

I think I need to do some extensive reading on:
A) How branching and merging works best for people
B) How to work with Visual Studio using branched projects

No comments: