Multiple VSS Databases

In Knowledge Base article Q127104 and in the VSS6 documentation, Microsoft recommended against using multiple VSS6 databases in simple cases. The support that was in some earlier versions of the product using Data Path doesn't seem to work at all well in some cases. And at first it can seem that VSS isn't even capable of operating with multiple databases. On the other hand, there are sometimes good reasons for using multiple VSS databases. And mechanisms for accessing multiple databases ­­sometimes better than the original Data Path mechanism­­ are available in every case (although often poorly documented).

Considerations for Multiple VSS Databases

Pro

• Quicker maintenance (ANALYZE, backup, etc.) You can for example do detailed maintenance on a different database each day of the week rather than having to do the whole thing all at once.

• Smaller granularity (In other words you can take a damaged part of VSS down without taking having to take the entire VSS system down.) The current "all or nothing" behavior of VSS is a real thorn in the side of many VSS administrators. In fact this shortcoming alone seems such a "scalability problem" that it makes VSS less than desirable for use in any organization larger than ten people. Multiple VSS databases mitigates this.

• Perhaps slightly (but not significantly) better performance.

• Slightly less risk of running into VSS bugs that tend to show up when VSS is stretched beyond its testing and its design center to handle a single very large database.

• If you have to "restore" a whole database, you at least don't lose all your organization's recent work.

Con

• Potentially a separate list of users for each database, with each user having a separate SS.INI for every database. (One of the configuration recommendations below negates both of these limitations, but maintenance will not be fully automatic. You definitely will have to "add" new users to each database separately, and you may also have to "just remember" to do a few additional manual steps whenever you add or change a VSS user.

• Separate "user rights" for each database. (It's very difficult to work around this limitation as the VSS tools for maintaining "user rights" are poor. In fact there's not even a way to "dump" a "user rights" database to text so you can scan or manipulate it yourself with your own text editing tools.) You could easily wind up facing a maintenance nightmare. One of the configuration recommendations below negates this limitation by simply "not using" user rights at all. You should seriously consider the option of not using "project security".

• Microsoft support may blame some hard problems on the multiple databases and say "we told you so", even if multiple databases really don't have anything to do with the problem you're asking them to help with.

• You cannot "share" files between multiple VSS databases at all. All you can hope for is that your source can be divided into multiple VSS databases along fairly natural project boundaries in such a way that there is virtually no need to "share" files between the multiple databases.

• It is difficult to bring your multiple databases into one centralized system. The configuration recommendation below of having one unified grand project hierarchy makes this easier. But you will still need to use the Archive and Restore utilities if you need to move a project from one database to another.

Configuration Recommendations

If possible do not use the project security option of VSS. Project security information is stored per-database. And even in the single database case maintenance of project security is relatively difficult. It's very difficult to maintain project security with multiple VSS databases. There's seemingly no way to synch up user rights across databases or to maintain rights for all the databases using a single interface. Your best bet is to just turn the project security option completely off.

Create in your head one overarching project hierarchy for all the databases. Sketch in this project hierarchy skeleton (at the very least the top couple levels of it) in every database. In each database at any given time some of these projects will be real while others will be empty (or will be present only as a "placeholder"). Doing this makes it much easier to rebalance the databases later by using SSARC/SSRESTOR to move a project from one database to another without losing any of the history information.

You can point the User_Path of all the databases to the same folder, and thus share a single set of SS.INI files among all databases. Users will probably like this because options changes they make while using one database will be in effect for all the other databases too. (The VSS default is to have a separate user folder of SS.INI files for each database. But you don't have to accept the default.) This should be relatively easy to maintain, although you may have to do a little manual editing outside of SSADMIN when you add a new user.

Accessing Multiple VSS Databases

From the VSS GUI

To start up the GUI pointing to a particular database, either check the "open this database next time I run Visual SourceSafe" box on the File|OpenSourceSafeDatabase... dialog, or specify

ssexp -s\\server\share\pathtofoldercontainingSRCSAFE.INI

in the shortcut or menu item that starts VSS. You can create several different shortcut icons each of which launches VSS against a different database this way.

To change to a different database after the VSS GUI is already running, use the File|OpenSourceSafeDatabase... dialog and [Browse] if necessary to the folder containing the SRCSAFE.INI file of the database you want to select. Once you do this VSS will add an item to the menu of possible databases by creating a registry entry. Next time you use the File|OpenSourceSafeDatabase... dialog the database will appear in the menu and you won't have to [Browse] to it.

From the SS Command Line CUI

Set the SSDIR environment variable to the folder containing the SRCSAFE.INI file of the database you want to operate on before invoking any SS commands. None of the SS commands takes a database selector as a command line line switch; they all use this same environment variable. Documentation of this is largely lacking. Documentation of most SS commands doesn't mention it at all. But it works!

Remember that if you use SET inside a command box, it affects only that command box not other existing command boxes or new command boxes or direct system launches. You should either make the setting through System|Properties.../Environment and then launch a new command box, or run all the SS commands in the same command box you just ran SET in.

From the MSDEV IDE

Typically project (.DSP) files contain information that points back to the VSS database where files for that project are kept. Typically for existing projects you don't need to worry about selecting which VSS database to use at all.

But MSDEV does get confused in special cases. One of these cases is if you manage to define different projects in the same workspace (.DSW file) as being stored in different VSS databases. MSDEV doesn't expect this to happen, and doesn't handle it very cleanly. You will have to change the MSDEV option Tools|Options.../SourceSafe[Advanced...]/Integration to Database=Prompt. Then every time you open a different project you will have to answer [Cancel] to the question "...Would you like to connect to this project?", [YES] to the question "...Would you like to browse for the project?", [Browse], and then select the correct VSS database.

When creating new projects you can handle choosing which VSS database to use in either of two ways. If you set Tools|Options.../SourceSafe[Advanced...]/Integration to Database=Use Default, all new projects will be put in the VSS database that your local SRCSAFE.INI points to. If on the other hand you set Tools|Options.../SourceSafe[Advanced...]/Integration to Database=Prompt, you will be presented with a menu of known VSS databases and asked to make a selection when you create a new project.