At last, SourceSafe redesign / rebuild is COMPLETED! Our main product has it's own VSS database now. I adopted partitioned single solution because there are too many projects for one single solution. I like this structure. You have to load only subset of all projects on your dev box. There is one master solution that contains all projects, all other sub-solutions are referencing projects from this master solution. It's also easy for managing builds (for more info see : Structuring Solutions and Projects)

I created folder structure inside VSS that we also re-created on all of our dev machines file systems (subst command rulez! :-). Having the same structure across all machines has many advantages, especially when you're referencing some external assemblies via file references. However, there is one problem when you have Compact .NET Framework projects inside solution. When you're doing Open From Source Control for the first time, VStudio looks only in one specific folder for assemblies referenced via File References (only for smart device Projects) (C:\Program Files\Microsoft Visual Studio .NET 2003\CompactFrameworkSDK\v1.0.5000\Windows CE). It's impossible to add another folder to let VStudio know where do you reference your assemblies from (you can add paths to References Path in project properties, but these settings are stored in user specific files (e.g. csproj.user). These files are NOT source-controlled). If you don't have assemblies in this path, Visual Studio removes references to affected assemblies from projects. Argh! It's really pain in neck to manually add all removed references to all projects on all dev machines. So we decided to reference required .NET CF assemblies from C:\Program Files\.. (we have VStudio installed in same path, so it's not *that bad*). For all other projects, Visual Studio uses <HintPath> element inside source-controlled project file (*.csproj). So as long as you have referenced assembly in same path on all machines, it's found without any problems.

VSS Structure (names changed for obvious reasons):

$/
   Projects
       CustomerName
           ProductName
               MasterSolution
                  _PartialSolution_1
                      _PartialSolution_1.1
                          Project_1.1.1
                      _PartialSolution_1.2
                          Project_1.2.1
                      Project_1.1
                  Project_1
                  Project_2
                  ...
                  Project_N
               WebSolution
                   WebProject_1
                   ...
                   WebProjects_N
               UtilsSolution
                   UtilsProject_1
                   ...
                   UtilsProject_N
               UIControlsSolution
                   UIControlProject_1
                   ...
                   UIControlProject_N
     
Directory Structure on dev machines (subst o: ...)

O:\Projects
    CustomerName
        ProductName
            CommonDLLs
            MasterSolution
                _PartialSolution_1
                    _PartialSolution_1.1
                        Project_1.1.1
                    _PartialSolution_1.2
                        Project_1.2.1
                    Project_1.1
                Project_1
                Project_2
                ...
                Project_N
            WebSolution
                WebProject_1
                ...
                WebProjects_N
            UtilsSolution
                UtilsProject_1
                ...
                UtilsProject_N
            UIControlsSolution
                UIControlProject_1
                ...
                UIControlProject_N
    
All PartialSolution_X are opening projects from MasterSolution (added with Add Project From SourceControl... in Visual Studio). Outputs from UtilsSolution and UIControlsSolution are referenced by projects in MasterSolution via file references from CommonDLLs folder (except .NET CF assemblies, see above) [note - watch out that CopyLocal attribute is set to true for each file reference). Assemblies from CommonDLLs are not under source control. WebSolution contains only WebServices that are referenced by clients via virtual folders created by IIS (Virtual folder path is identical across all clients (http://localhost/WebProject_X). [note - you cannot create virtual folder on virtual drive created by subst].

I'm "proud to announce" :-) that this redesign cut down our get-latest, check-in / out, build-to-test time by cca. 30 - 40%! Having smaller number of projects in one solution really makes difference! Also we are able to minimize situations when we build against older version of an assembly (MissingMethodException and TypeLoadException were killing us). It was hard for me as a dev to spend 4 days in VSS trying to understand how it operates and rebuilding our database. However I learn a lot, so hope it was worth that time... ;-)

Recommended reading :
Microsoft Team Development Guide
Microsoft Team Development Guide [pdf]
Visual SourceSafe Version Control: Unsafe at any Speed?

Recommended script:
With help of google I was able to create this simple script for doing daily backups of our VSS database (scheduled task in W2k3) - date delimeter is '.' in my country. It's not exactly same as we are using, but you'll get the idea...:

REM returns date in YYYYMMDD format
FOR /F "TOKENS=1* DELIMS= " %%A IN ('DATE/T') DO SET DATE=%%B
FOR /F "TOKENS=1-4* DELIMS=. " %%A IN ('DATE/T') DO SET MYDATE=%%D%%B%%C

MKDIR D:\_SOURCES\_BACKUP\%MYDATE%\<VSSDB_NAME>
XCOPY D:\_SOURCES\<VSSDB_NAME>\*.* D:\_SOURCES\_BACKUP\%MYDATE%\<VSSDB_NAME> /E /H

Now I'm planning to look closer on our build process... :-)

*enjoy*

<edit>
Added interesting link about known VSS "defects"
Added description to script
</edit>