How To: Split a VSS Database into Two or More Databases


[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,



  1. Delete versions, files, or projects or
  2. 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:



  1. In VSS Administrator, open the source database and use the Archive Projects wizard to archive selected projects.
  2. 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:



  1. Backup projects outside a database in order to reduce the size of the database, improve performance, and reduce the risk of data corruption and,
  2. 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:



  1. Lock all users out of the existing database (db1).
  2. 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.
  3. Using VSS Administrator, create a new, empty database (db3).
  4. In db2, rename um.dat as um.dat.bak.
  5. 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.
  6. 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.
  7. 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.
  8. In db2, delete all projects and files that you wish to keep in db1 to ensure that it is a manageable size.
  9. In db1, delete all projects and files that you did not delete from db2 to ensure that it is a manageable size.
  10. Unlock db1 and notify your users that it is once again available.
  11. 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. ????? ?? ?????? “??? ????” ??? ?? ?????? ?? ??????, ????? ????? ?? ?????? ????.

Comments (28)

  1. Martin Brown says:

    So how do we get hold of this tool for moving users between VSS databases?

  2. Hej Martin, went to your site but couldn’t find an email address. I can mail you a zip file containing the VSSEMS tool if you want.

  3. AsbjornM says:

    Is this tool finished now?, I got an beta earlier, and would like an new if it is done.

  4. Hmmm. I think that this tool is in perpetual beta. You can report any bugs you might encounter to vsstools amper. dot microsoft dot com. Perhaps somebody on that alias can tell you if you have the latest version or not…

  5. Jonathan Moore says:

    would really like PSS tool for migrating users from on SS db to another!

  6. Jonathan, I’ll post a link to a little utility I’ve been developing in the near future. Stay tuned. -Korby

  7. Chris Watson says:

    Can you tell me how to get hold of the tool for transferring user details from one VSS database to another?
    Thanks, Chris

  8. James Beverley says:

    Hi – I’d really like to get hold of this user copy utility too as we’re doing a lot of VSS db copying.

    Thanks

  9. Thanks to Birschoff for notifying me of a technical inaccuracy in this post. I have changed,
    — "A less obvious but arguably more effective way to delete data is the Rollback command, which destroys all versions of a file prior to the one selected."
    TO:
    –"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."

  10. Muthu says:

    Like to have a copy of the User database tool. Could you please sent it to my email address

  11. PG says:

    Hi Korby,

    Can i please get the tool to copy user rights from one DB to the other?

    Thanks and keep up the good work.

    PG

  12. JeffD says:

    Could I get a copy of the user migration tool or a link to it, too?

    Thanks much!

    -Jeff

  13. Sean Roberts says:

    Me too, where can I get this user copying tool.

    sean.roberts@cit.com

  14. Chris Barr says:

    Could I get a copy also? Thanks.

  15. Peter Carberry says:

    Please send me the tool to copy users and Thanks! pcarberry@dexterra.com

  16. Joey says:

    Hey Korby, I’d love to get my hands on that Utility…

    Please send it to my E – Mail below:

    ninja@bezeqint.net

    Thanks again Korby!

    — Joey

  17. Jon Booth says:

    Korby – This site is an awesome resource! I’d love to get the user copy tool as well as a have a huge VSS DB migration on the horizon. jon@scriptingoff.com

    Thanks!

  18. Kelly Klipple says:

    I’d also like to get the user copy tool.

    Thanks!

    kklipple@bigfoot.com

  19. Nick says:

    Could i please get a copy as well ! Many thanks ! nicknexus@hotmail.com

  20. Cynthia Kong says:

    Hi,

    I would like to get a copy of the tool as well.

    Thank you so much.

    Cynthia

    cynthiak_2001@yahoo.com

  21. Good Article. Can I get some information on that user migration tool. Thanks.

  22. Deepak Michael says:

    I’d love to get my hands on the user migration utility. Please mail me at deepakmichael@hotmail.com

  23. Joe says:

    And a "me too!" here. Please send to microsofttool ATMARK joepetrow.com

  24. Gordon says:

    Good Article. Can I get some information on that user migration tool. Thanks.

    gordon@elginonline.co.uk

  25. Yes, you can now download this utility from http://www.winisp.net/korbyparnell/vssems.zip.

    I’ve updated this post as well.

  26. adeles says:

    Do any one here know how to sychronize 2 database folders?

    We have 2 VSS database folders in 2 different servers, we want to sychronize them into 1, but we have some problems here. Thanks for the help.

  27. Rupesh says:

    If the VSS explorer windows does not opens or

    if it consumes 100 percent CPU time, then what is the solution?