CODEWITHSUNDEEP
version-controlvisual-sourcesafe
Anemoia
Anemoia

Reputation: 8116

Visual Sourcesafe, sharing: commits to wrong location

I have a project under my management.

It has the following structure:

$/Code/MainSolution $/Code/Branches

I want to branch the MainSolution in $/Code/Branches

So I do it, (it works perfectly), I set a working folder for that project and do a 'get latest'.

But when I open that solution in Visual Studio 2005 it identifies every file as new (+ sign in front of the file) and when I commit it it goes to

$/Data/NameOfTheBranch

Why does it do that? Why doesn't it follow MY rules?

Upvotes: 1

Views: 673

Answers (2)

Mark Tolonen
Mark Tolonen

Reputation: 177640

  1. Go to File, Source Control, Change Source Control (at least on VS2008).

  2. Look at the Server Binding column. Generally you want the binding to point to the solution's root project directory in VSS for the solution and all the projects. If not, then:

  3. Unbind all the projects and the solution.

  4. Shift-select the entire list.

  5. Bind everything to the solution root.

If you do this before branching and pinning the project, it will be easier. Doing it afterward you will have to branch the .sln file and perhaps the .vcproj and the .vspscc as well for the modifications to be saved correctly.

Here's a good reference for the files VSS and Visual Studio manage. These files can easily get out-of-whack.

I administered a VSS database for too many years and recently switched to Mercurial and haven't looked back. Branching and merging in VSS is horrible.

Upvotes: 1

MK.
MK.

Reputation: 34527

I usually make all vcproj files under solution have the following:

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

This will make it pick up the sourcesafe information from the solution file. Make sure solution file is branched, not shared in the 2 branches. Open the branched solution and then go to "Change Source Control" and bind the solution to the correct location in SourceSafe.
This is all rather fragile (or perhaps I don't fully understand it) but I usually just poke at it until it works. And, as usual: if at all possible migrate to a different source control system. Perforce, Subversion, Mercurial...

Upvotes: 2

Related Questions