VSS and SOS are fighting!

dprice · Post by **dprice** » Thu May 27, 2004 1:57 pm

Hello,

We're in the process of evaluating SOS and so far it has been amazing for us remote users. I've informally measured increases from 5x to 50x depending upon the task. However, we have run into a snag. We have two VSS databases that are used by separate groups and both are seeing this. Both groups are using VS.NET 2003 with C# projects. Both groups have one remote developer using SOS and the rest are on-site using VSS. Both groups have their solutions bound to VSS and thus the fighting starts. When VS.NET/VSS created the solutions it saved the project information in the project files (.csproj) with this:

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

However, when SOS gets a project from VSS, it wants to change the the above fields to :

SccProjectName = "$/<some explicit path>"
SccLocalPath = "."
SccProvider = "MSSCCI:SourceOffSite"

So when the on-site users open the solution, it immediately wants to check it out and it's a constant battle between the two programs. Has anyone else seen this? How do we stop this endless tug-of-war?

Thanks in advance!
Derek

corey · Post by **corey** » Tue Jun 01, 2004 8:01 am

Are you evaluating SOS 3.5 or SOS 4.0?

dprice · Post by **dprice** » Tue Jun 01, 2004 8:23 am

We're using 4.0.1.

corey · Post by **corey** » Tue Jun 01, 2004 8:35 am

Are you initially retrieving the project with SOS by doing an "open from source control" within VS.NET?

dprice · Post by **dprice** » Tue Jun 01, 2004 8:44 am

Not necessarily. On my project, we usually use VSS/SOS externally to get the latest versions, but since the solutions are bound to VSS, the IDE always connects to VSS when they are opened locally. The other group in our company always uses the open solution from VSS option.

corey · Post by **corey** » Tue Jun 01, 2004 9:28 am

If the projects already exist on the developer's machines, having been previously integrated with VSS, the existence of MSSCCPRJ.SCC files with VSS bindings could cause problems. Try this:

1. Check in any changed files on the developer's machine into VSS.
2. Back up and then remove the solution from the developer's machine.
3. Then start VS.NET and perform an "open from source control". This should refetch the project and bind it with SOS without needing to change the .sln and .proj files.

dprice · Post by **dprice** » Tue Jun 01, 2004 9:55 am

Since this solution seems only to apply to remote users (using SOS), what happens to those developers in-house using VSS? Do they have to do the same steps?

shaundodimead · Post by **shaundodimead** » Tue Jun 01, 2004 10:21 am

Derek,

Only today have i managed to get a solution to this that I think works for me. We have remote developers who use only SOS and local devs who use only VSS, i'm not sure if this setup fits yours. We are using SOS 4.0.2.

Basically we have the issue where when our SOS users pull projects (or open existing solutions) VS.NET decides it wants to checkout all the project files and change the SCC provider, if we do this is screws all our VSS users etc. You can stop vs.net checking out the projects but then you cant add files extra through visual studio, it adds them to the local project files but those files are not checked out, so the updates never get back in.

The solution which is working for me is to convince VS.NET 2003 that it's working with Visual SourceSafe when in reality its working with SOS, I think this'll only work for people who use either VSS or SOS rather than both (however i'm sure you could use regscripts etc to work around it).

Anyway, i'm doing this:

1. Set SOS as your default SCC
2. Open regedit

3. Open HKEY_LOCAL_MACHINE\SOFTWARE\SourceOffSite\SourceOffSite and set SCCServerName to Microsoft Visual SourceSafe from SourceOffSite
4. Open HKEY_LOCAL_MACHINE\SOFTWARE\SourceCodeControlProvider and check ProviderRegKey is set to Software\SourceOffSite\SourceOffSite
5. Open HKEY_LOCAL_MACHINE\SOFTWARE\SourceCodeControlProvider\InstalledSCCProviders
6. Rename Microsoft Visual SourceSafe to Microsoft Visual SourceSafe2
7. Rename SourceOffSite to Microsoft Visual SourceSafe (so basically Key:Microsoft Visual SourceSafe Value:Software\SourceOffSite\SourceOffsite)
8. Open your VSS solution file

If by now your PC hasn't been consigned to the rubbish bin, you may find that VS.NET thinks your VSS solution file is fine, and will just let you log into 'Microsoft Visual SourceSafe' (SOS) as normal.

This method seems to allow me to add files, mess about with projects etc and totally interact with my VSS using pals.

If this works for you great, if not sorry to have destroyed your registry, but you made a backup right?

Shaun

corey · Post by **corey** » Tue Jun 01, 2004 10:35 am

dprice wrote:Since this solution seems only to apply to remote users (using SOS), what happens to those developers in-house using VSS? Do they have to do the same steps?

No, they shouldn't need to as long as the .sln and .proj files do not get modified by VS.NET.

dprice · Post by **dprice** » Tue Jun 01, 2004 10:54 am

Thanks to everyone for all the help. I have a few things to try now!

Pawel_Lamik · Post by **Pawel_Lamik** » Wed Jul 14, 2004 2:51 am

shaundodimead wrote:Derek,

This method seems to allow me to add files, mess about with projects etc and totally interact with my VSS using pals.

If this works for you great, if not sorry to have destroyed your registry, but you made a backup right?

Shaun

This worked for me with SourceOffSite 4.0.2. Vs.Net does not ask to check out project files any more

dprice · Post by **dprice** » Wed Jul 14, 2004 8:41 am

I think the solution is at this support post [1], but I have not had a chance to try it yet.

[1] http://support.sourcegear.com/viewtopic.php?t=1149

Thanks,
Derek

SourceGear Support

VSS and SOS are fighting!

VSS and SOS are fighting!

Solving this issue

Re: Solving this issue