Branching with Visual Studio .Net 2003 Integrated

[George Mills]

I mentioned the issue in another thread how VS .Net hard codes references in .xxprog files that point into the source archive which messes up integration when branching.

So I'm asking how do developers here handle branching with VS .Net integrated projects.

The issues are:

1) The hard references in .xxprog files
2) When you branch you get a new project folder somewhere in your tree and again the .xxproj files know nothing about this change. Some source control systems always give you the same directory layout regardless of the branch you are interested in. They just say give me the tree with this branch.

So the options I see are:

a) Don't branch. Don't laugh that's pretty much what we have been doing. we've waited as long as possible before checking in code on the next release. And used label promotion to add changes to that release tag once we start checking in. painful.

b) Create 1 sln for the trunk and 1 for each branch. Again a bit painful.

c) always branch the whole tree above the sln file. this was scary in VSS with a large tree. And repository will grow very fast doing this. I have more confidence with Vault. This still has problem #1 but solves #2.

d) Do c) but give up on IDE integration to solve #1 or do b) to fix it up.

e) for those that want the trunk, don't override any working driectory. For those who want a particular branch, override inherited working directory of project to original name. This made me nervous in VSS and requires a LOT of care on each developer doing the right thing. Also you have to override the working directory on the trunk project to something else to avoid name conflict. This still has problem #1 but solves #2.

f) Do e) but give up on IDE integration to solve #1 or do b) to fix it up.

How do you do it?

P.S. Vault Merge Wizard is awesome.

[dan]

I believe there are ways to manually update the project files to get them to point to the right place. See http://support.sourcegear.com/viewtopic.php?t=194 for how to do it for web projects - it may apply to regular projects too.

We don't use the IDE component for development here, so we don't run into this problem, so I can't give advice on how we do it But, I would never discourage anyone from using the standalone client as their primary SCC method

I wouldn't recommend branching higher in the tree to workaround the problem. Increasing the number of nodes in your source tree will eventually slow the client down.

[George Mills]

Ok thanks for the warning on "over branching". I was always cautious in VSS about this but I didn't know if Vault might be super efficient around this and not bite us in the long run. I thought if it internally shared the tree until a change on either the trunk or branch was made it might be fairly cheap. Maybe you do this sort of thing but your saying the number of "nodes" still goes up fast.

Regarding your reference to web based projects. It's no different on desktop projects. I always manage to bumble it, or VS IDE crashes in the middle or it does not know to checkout solution manually first etc. It's a pain to have to maintain Solution files for every combination of branches just because some developer wants to just branch even 1 source file.

The primary feature I like in integration with IDE is automatic checkout. Maybe if you guys could slip in with a File Driver and see the attempt to write a read only file. The Vault IDE could pop a "Do you want to check it out".

[dan]

A possible solution would be to use the "Don't Require Checkout Before Checkin" feature of the standalone client (under Tools->Options->Checkin. You can start editing files, and they will automatically show up in your pending changet set after you've saved the file. This is how CVS users work, and it is quite handy once you start to trust it