Branching best practices with Visual Studio 2003?

stevefish · Post by **stevefish** » Mon Jan 23, 2006 9:52 am

My team is just starting to use branching with Visual Studio 2003 projects in Vault. I've read the posts here about having to unbind/bind the solution and web projects so the files will be checked out from the branch and not the trunk.

(See http://support.sourcegear.com/viewtopic.php?t=1917 and http://support.sourcegear.com/viewtopic.php?t=194 )

But so far my experience is that EVERY project in the solution needs to be re-bound before everything will work correctly. Not just web projects and the solution itself, every project. I would like to know if anyone has experience with branching with Vault and Visual Studio solutions in the real world, and if you can share some best practices.

So far, I'm planning to do the following after I create a new branch:

1. Check out each .sln file using the Vault client.
2. Use a text editor to edit every "SccProjectNameX" line in the .sln file to point to the correct branch location in Vault.

I know I could do step 2 using Visual Studio's Change Source Code Control command. But we have 10+ solutions that need to be fixed every time we branch. I'm going to write a batch script to edit the sln files instead.

3. Check the sln files back in.

This seems like an awful lot of hassle, but it's the best method I can find so far. Is there a better way??!

Thanks
Steve Fisher

stevefish · Post by **stevefish** » Tue Jan 24, 2006 2:10 pm

Can someone from SourceGear please respond? I need assistance on this. Thanks

dan · Post by **dan** » Tue Jan 24, 2006 2:27 pm

Sorry not to respond sooner - yes, unfortunately you do have to update each project affected by the branch, and a script file (once it is coded) would be easier to use than doing the Change Source Control for each one. You just need to remember to check out the project files and check them in once you've made the changes via the script file.

stevefish · Post by **stevefish** » Tue Jan 24, 2006 2:46 pm

Thanks. That's what I was afraid of. OK, I guess I can live with that.

The information I found in your KB on this topic was only in reference to web projects. If you haven't already (I sure didn't find it) I suggest you post an article in your KB stating that ALL projects in a branched solution need to have their SCC bindings updated. I was little misled by jeremy_sg's post stating only web projects need this fix (http://support.sourcegear.com/viewtopic.php?t=194).

mlippert · Post by **mlippert** » Tue Jan 24, 2006 4:04 pm

FYI, at least for VS 2003, it is possible to only have to update the MSSCCPRJ.SCC files. However in order to do that, your project and solution files have to be in a very particular state, and I've only been able to maintain that state by hand editing the project and solution files, which is a pain when you add a new project to a solution, and Visual Studio screws it up.

But, we have 5 or 6 solutions and easily 50 projects, and when I create a branch all I do is check out the MSSCCPRJ.SCC files (there's one associated with each solution that we check in), change the repository paths in that file and check it back in.

However, most times that a developer uses Visual Studio to change the source control information stored in the solution or project it breaks it (as far as this issue is concerned), and it needs to be hand edited again.

Mike

The source control info in the project files (*.vcproj) looks like:

Code: Select all

SccProjectName="SAK"
SccAuxPath="SAK"
SccLocalPath="SAK"
SccProvider="SAK"

And the source control info in the solution files needs to be in the relative path format which looks something like:

Code: Select all

SccProjectUniqueName1 = mathcast\\mathcast.vcproj
SccLocalPath1 = .
CanCheckoutShared = true
SccProjectFilePathRelativizedFromConnection1 = mathcast\\

IIRC the path in the associated project must also be a relative path, the SccLocalPath must always be '.' while the other paths should be the full relative path to the project from the solution file's folder. (I don't feel like messing up one of our solutions to get the counter example.)

This info was gleaned via experimentation and from tidbits found around the net, but not from any actual Microsoft documentation so use at your own risk.