views:

89

answers:

2

Basically, what I want to achieve, is to be able to have 2 separate solutions containing the same set of projects, but 1st solution needs to be bound to source control, 2nd - not.

So whenever you want source control integration in Visual Studio, you can open 1st solution, but if you don’t want it, you can open the 2nd one.

The problem is, that VS stores some binding info in the project files, and while it is there, no matter what solution the project is part of, it will have source control integration when opened in VS.

Is it possible to have all the binding info in the .sln file only?

Or maybe there is another solution form my problem?

Edit: the reason I want to do that is because some of the team members prefer to have source control integration in Visual Studio, the others don't. Having 2 solutions would give them a choice.

+2  A: 

No.

It couldn't be the same set of projects - the files in a project are either source controlled or not, but you could have a non-source-controlled copy of a version retrieved from source control.

You could probably automate the process of removing source control bindings. So you would get a solution from source control, make a copy, and remove the source control bindings from the copy.

I've needed this in the past in the following situation: a source-controlled solution with a shared class library and a sample application that uses the shared library. I wanted to be able to ship a ZIP file containing the sample application without source control bindings.

Joe
A: 

This is technically possible. Open the File -> Source Control -> Change Source Control dialog and you can adjust the bindings for each individual project, including the root solution. However, it probably won't do what you want. If you remove the bindings from the projects but keep the solution binding, you'll end up in a state where changes to the solution itself (e.g. stuff you do in Configuration Manager) are automatically checked in & out, but changes to files that are "owned" by the individual project systems won't be.

The best answer IMO is to have the developers who don't like SCC integration adjust the settings in Tools -> Options -> Source Control -> Environment to their liking. Here you can turn off most (all?) of the SCC features that act "behind your back." And they are all strictly per-user, stored in the HKCU registry rather than your makefiles.

Richard Berg