SourceSafe Q & A: Multiple Databases

** SourceSafe Question **

Although SourceSafe organizes files into projects, all the files and projects
are stored together in one database.  Is there any way to divide my SourceSafe
projects among more than one physical database?

** Why We Don't Recommend Multiple Databases (...if you can possibly help it)
**

This document gives a number of ways to set up SourceSafe with multiple
databases.  However, if at all possible, we strongly recommend against doing
so, for three reasons.

1. You cannot Share files between multiple databases.

2. You cannot move files from one database to another (except by Getting from
one and Adding to the other, which loses all history and linking information).

3. If you ever decide to bring your multiple databases back into one
centralized system, there is no way of doing so.

For these reasons, whenever possible, we recommend organizing into projects
within a single database.  However, if multiple databases are actually
necessary--for instance, if you don't have a drive large enough for all your
code--the following scenarios provide three possible ways to set it up.

** The Brute Force Method: Multiple Installations **

The simplest solution is to simply install SourceSafe more than once.  This
creates separate installations of SourceSafe, with separate databases, which
know nothing about each other.

However, in addition to having two databases, you now have two of everything
else.  You have two of all the executables and help files, which is
inefficient; and you have two SS.INI files for every user, which is confusing. 
The next two solutions suggest improvements on this scheme which, although
similar in their end result, considerably reduce the file redundancy.

** The Better Solution: Multiple SYSTEM.INI Files **

The key to a better solution lies in understanding how SourceSafe finds its
database.  First, SourceSafe uses the environment variable SSDIR to find the
file SYSTEM.INI; then, it looks for the Data_Path variable in that file to find
the DATA directory which contains your files and projects.

That being understood, you could create a multi-database SourceSafe
installation using a process such as the following.

1. Install SourceSafe to R:\SS.

2. Copy the SourceSafe DATA directory from R:\SS\DATA to R:\DATA2.

3. Create a file called R:\SYSTEM.INI containing the following two lines.

#include R:\SS\SYSTEM.INI
Data_Path = R:\DATA2

You now have two valid SYSTEM.INI files, identical except that they point to
different DATA directories.  If you set the environment variable SSDIR to
R:\SS, you will see the first SourceSafe database; if you set it to R:\, you
will see the second.

Although harder to set up, this is a considerable improvement over the brute
force solution.  It enables you to switch between installations by simply
changing an environment variable, rather than running a different program
entirely; and more importantly, all other files such as the executables and
SS.INI files exist only once.

** The Ultimately Elegant Answer: Multiple Data_Path Settings **

Warning: this particular section gets a lot more complicated than anything else
in this paper.  Skip right over it unless you're prepared to cross your eyes
for about half an hour.

Every variable in SYSTEM.INI can be followed by a platform specifier in
parenthases.  This enables one variable to have different settings on different
platforms.  For instance, the following variable has different settings under
the PC and Macintosh.

Shadow (PC) = R:\Masters\Shadow
Shadow (Mac) = Server:Masters:Shadow

Different versions of SourceSafe look for different specifiers; for instance,
SourceSafe for Windows NT looks for the following.

NT, Win, PC

This means that it looks for a variable set for "NT"; if it does not find that,
it looks for "Win"; then "PC"; and finally, for a variable with no platform
specifier.

Under SourceSafe 2.12 or higher, you can set an environment variable to change
the platform specifiers SourceSafe looks for, by setting the environment
variable SSINIENV.  For instance, suppose a DOS user types the following:

Set SSINIENV = Bob, DOS, PC

SourceSafe would then look for variables specified for "Bob" before looking for
DOS, PC, or no-specifier.  Now our hero places the following two lines in
SYSTEM.INI.

Data_Path (Bob) = R:\SS\DATA
Data_Path (Sue) = R:\SS2\DATA

SourceSafe will use the first setting, and ignore the second.  With a different
setting of SSINIENV, SourceSafe will use the second string and ignore the
first.  Hence, by setting the SSINIENV variable appropriately, you can control
which Data_Path variable SourceSafe reads; and hence, which DATA directory is
used!  This solution provides the ultimate in flexibility, but it is clearly
not for the faint of heart.

** A Few Final Notes **

Once you have created multiple databases, using any of the above scenarios, you
will need to note two final issues.

1. It is not possible to switch databases from within SourceSafe; you decide,
via environment variables, where the data is before you run SourceSafe.  To
look at the other database, get out and run SourceSafe again.

2. For security reasons, SourceSafe's list of users and passwords is stored
with the data.  (It has to be that way--trust us.)  Hence, even if you have
only one SS.INI file per user, you will have to maintain two separate user
lists.  This can be a considerable boon, if security was the reason you wanted
separate databases in the first place.  But to add a user to both databases,
you must actually add him twice.

You now have all the tools necessary to create and maintain multiple SourceSafe
databases, using any of the above scenarios or variations on them.  Of course,
as always...if you have any questions or problems, call One Tree Software
technical support for further assistance!

