[In this post, I provide a previously undocumented method for dividing the contents of one database into two or more databases.]
Theoretically, the size of a SourceSafe database is limited only by the size of the partition on which it resides. If you’re really inventive, you can probably even figure out how to make a VSS db span partitions… In practice though, Microsoft recommends that you keep your databases below 5 GB (and always on one partition).
If your database is larger than 5 gigabytes, you should run Analyze at least once a week and you should consider reducing its size. There are two ways to shrink a database. You can,
- Delete versions, files, or projects or
- Move versions, files, or projects.
Methods for deleting data from a SourceSafe database are both manifest and well-documented but let’s take a brief look at each. You can selectively delete SourceSafe projects and files using the Delete command (in combination with the ‘Delete Permanently’ option in the Delete file dialog box) in VSS Explorer or from the command line. From the command line, it is not possible to recursively Delete or Purge versions, files, or projects. A less obvious but arguably more effective way to delete data is the Rollback command, which destroys all versions of a file newer than the one selected. The Rollback command is available in the History window or from the command line. It makes sense to destroy data using the Rollback command if you store large binary files in your database (ie, .doc, .dwg, .xls, etc), if you’re not too concerned about maintaining a cohesive history of your files and projects, and if you don’t use the Share or Label features very often. If you do use Rollback to delete versions of a file from history, USE CAUTION, especially if you work for the government.
In most cases, it is safer and easier to move data rather than delete it. The documented method for moving projects from one database to another is as follows:
- In VSS Administrator, open the source database and use the Archive Projects wizard to archive selected projects.
- In VSS Administrator, open the destination database and then use the Restore Projects wizard to restore the archived projects into the [current] destination database.
The Archive & Restore feature was designed to accomplish two tasks:
- Backup projects outside a database in order to reduce the size of the database, improve performance, and reduce the risk of data corruption and,
- Move projects from one database or another.
The Archive & Restore feature was not designed to make two databases from one. If you do need to split a database you need to know that Archive & Restore:
- Cannot copy a user list and rights/assignments from one database to another.*
- Does not allow you to move files from the root project ($/) of one database to the root project of another database.
In other words, Archive & Restore does an okay job unless you have files at the root of your database. This is especially important if any of the files at the root of the database are linked to or grouped by label with files in other projects.
Unfortunately, there’s no shipped workaround* for the first limitation. However, you can workaround the second limitation by splitting a database using the following method:
- Lock all users out of the existing database (db1).
- In Windows Explorer, copy the existing database (db1) directory to a new location (db2).
The database directory is the folder that contains the srcsafe.ini file, /data and /users directories, et al.
- Using VSS Administrator, create a new, empty database (db3).
- In db2, rename um.dat as um.dat.bak.
- Copy um.dat from db3’s /data directory to db2’s /data directory.
This is the step that necessitates this whole convoluted process. Basically, you can’t create a database by copying an existing one to a new location because each database has unique identifier that only VSS knows how to create. So in this step, we’re tricking db2 (which is a duplicate of your existing database) into thinking it is a new database (db3). Unfortunately, as you’ll see below, we can’t trick it into thinking that the user list is new as well. You’ll have to reconstruct the user list* and rights/assignments separately.
- In db2’s /data directory, rename rights.dat as rights.dat.bak and then run Analyze -F on db2.
This step rebuilds rights.dat using the blueprint contained in um.dat. Essentially, rights.dat is tied to the um.dat file. This step results in the creation of a new rights.dat for db2 that its um.dat recognizes. Uff da.
- Open db2 using VSS Explorer, confirm that you can access data using the Admin account and then delete um.dat.bak and rights.dat.bak from db2’s /data directory using Windows Explorer.
- In db2, delete all projects and files that you wish to keep in db1 to ensure that it is a manageable size.
- In db1, delete all projects and files that you did not delete from db2 to ensure that it is a manageable size.
- Unlock db1 and notify your users that it is once again available.
- Reconstruct the user list for db2*.
*Currently, it is not possible to migrate or copy a list of users and their concominant rights/assignments from an existing VSS database to another one, using either shipped VSS features or programmatically, using IVSS. However, our capable friends in Microsoft’s Product Support Services (PSS) have developed a tool that can perform this task automatically. To download this tool, click here.
This posting is provided “AS IS” with no warranties, and confers no rights. Microsoft kann für die Richtigkeit und Vollständigkeit der Inhalte in dieser Newsgroup keine Haftung übernehmen. Este mensaje se proporciona “como está” sin garantías de ninguna clase, y no otorga ningún derecho. Ce message est fourni en l état, sans garantie d aucune sorte, et ne vous confère aucun droit. Vous assumez tous les risques liés à son utilisation. Il presente posting viene fornito così come é , senza garanzie, e non conferisce alcun diritto. ????? ?? ?????? “??? ????” ??? ?? ?????? ?? ??????, ????? ????? ?? ?????? ????.