It's pretty much up to the project to persist these 4 values any way the project likes.
In C# or VB project files these strings appear in the PropertyGroup section of the project:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>
</PropertyGroup>
Similarly, in a VC project the strings appear as attributes on the VisualStudioProject xml node
<VisualStudioProject ....
SccProjectName="SAK"
SccAuxPath="SAK"
SccLocalPath="SAK"
SccProvider="SAK" .... />
Or in a Setup project files the strings appear as follow:
"DeployProject"
{
"SccProjectName" = "8:SAK"
"SccLocalPath" = "8:SAK"
"SccAuxPath" = "8:SAK"
"SccProvider" = "8:SAK"
....
}
So, what are these strings and what is their meaning?
The 4 strings are used to store the source control bindings of a project. The source control integration and the project exchange these strings using SetSccLocation and RegisterSccProject function calls, and the projects persist the 4 values in settings with names resembling the function arguments (lpszSccProjectName, lpszSccLocalPath, lpszSccAuxPath, lpszSccProvider)
VisualStudio 2003 and older supported only MSSCCI source control providers for scc integration. In MSSCCI, the IDE (VS) needs to persist 3 connection strings (the strings are required for the SccOpenProject calls). The connection strings are provider-dependent, and VS stores these 3 strings plus a 4th one (identifying the provider) in the solution and project files. However, storing the real bindings in the project files makes life harder for developers if the projects are moved either in source control or on local disk, or if the projects are branched, etc. To reduce these problems, VisualStudio tries to take advantage of the settings persisted by the source control provider in the mssccprj.scc files (when possible), and stores in the project files just a flag that tells the scc integration package that the project is under source control. The real bindings are persisted by the scc provider (in the mssccprj.scc files) and VS reads them from there and uses them when needed.
And there you have it: when all 4 source control connection strings in a project have "SAK" values, this is just a flag that tells VS that the real source control bindings of that project are persisted by the MSSCCI scc provider (not by Visual Studio) and should be read from the mssccprj.scc file written by the scc provider in the same folder as the project file.
To my knowledge, the "SAK" strings are the initials of Sumedh A. Kanetkar who worked for source control integration back in 2000 (could it be a coincidence?), but that's not very important. The strings could have been any distinct values that could be recognized later and used as a flag (except empty values - empty string values are understood by projects as "the project is no longer under source control" in the call to SetSccLocation).
Recently, I've seen another interesting interpretation of these values for Team Foundation Server provider. In this forum post Richard says "SAK" stands for "Should Already Know", because TFS should be able to determine the source control bindings implicitly.
This is more or less true for TFS.
Technically, TFS has enlistment/workspace management functionality, and this information is stored on the TFS server, not on the client. Thus, TFS is always able to calculate the source control bindings of a project, so it's true, TFS provider "should already know" the scc bindings of a project just based on the location of the project file on disk, and it doesn't need to persist real bindings in the project files.
TFS scc provider in VS2005 and later is a VSIP source control provider, that has full control over what information is written in the solution and project files. TFS could have used and passed any other string values to the project systems to be persisted in the project files.
To work with VS 2003, TFS also implements a MSSCCI provider that creates mssccprj.scc files (so when a project is added to TFS in VS2003 the scc bindings are usually written having SAK-values with their MSSCCI sense). To make easier the migration path (when such VS2003 project is opened in VS2005) it makes sense to me that TFS would re-use the same SAK strings for TFS VSIP provider. I suspect this is one of the reasons TFS source control provider in VS2005 and VS2008 also writes SAK values for the 4 binding strings.
