Stupid VSS Trick #2  '-D' stands for Deprecated.

VSS admins are constantly asking how to copy database settings, such as user list, permissions, custom srcsafe.ini variables, and user-specific ss.ini settings from an existing database to a new one. To date, the documentation has not ventured very far into this thorny thicket.

Some VSS database settings, such as certain srcsafe.ini settings, are easily copied to a new database. However, the process can be manual and error prone. Other settings, such as user list and permissions, are extremely difficult to replicate across databases.  I am happy to report that the super-smart and insanely responsive members of the VSS product support team recently developed a user list migration utility. For a copy of this utility, you can leave me your email (obfuscated to avoid email collecting spam agents) in the comments for this post and I will send you the files asap. The utility, which is still being tested, has not been released to the Microsoft Product Support Services site. When it does go public, I will post an announcement on this blog and will probably do so on http://msdn.microsoft.com/ssafe as well.

As I was saying, some settings are easy to copy from database A to database A1 and A2, and some settings are not.  However--and this is where the stupid VSS trick begins--there is an undocumented, gotcha-ridden, and "officially deprecated" way to create and configure one database to your liking and never do so again for subsequent databases.  If you're familar with IIS, this hack is similar to correlating IPs with friendly NetBios names in the LMHOSTS file.  In short, don't try this at home kids.

  1. Using the VSS Administrator user interface, create a new database called db_template in C:\Trash.
  2. In VSS Administrator, create two or three users. At least one of the users should be Read-Only.
  3. Open Windows Explorer, browse to C:\Trash and copy the \Data directory to C:\Delete.
  4. From C:\Trash, copy the User.txt file to C:\Delete.
  5. Click Start, click Run, type "C:\Trash\srcsafe.ini", and press Enter.
  6. In Notepad (or your favorite editor), find the line "Data_Path = Data".
  7. Directly beneath that line, type "Data_Path (db2) = C:\Delete\Data", where (db2) is a variable--or database alias--to which you will later refer.
  8. Close srcsafe.ini and all VSS applications.
  9. Click Start, click Run, type CMD, and then press Enter.
  10. At the command prompt, Change Directory to C:\Trash.
  11. Type "SET SSDIR=C:\Trash" (this and the precending step may be unnecessary but there's no reason to not do them.)
  12. Type "SSEXP.EXE -Ddb2" and then press Enter.

You can create as many empty 'databases' as you want in this way, copying the \Data directory and Users.txt file from db_template to other filesystem or network locations and then referring to them by alias using the -D switch. Conceivably, you might then create desktop shortcuts to the various databases that run a DOS command like SSEXP.EXE -Ddb3 or SSEXP.EXE -Dmydatabase.

Weirdness #1: Open both db_template and db2 in separate instances of SourcSafe Explorer. Look at the title bars for each...  They both read "Visual SourceSafe Explorer -- db_template ".  To confirm that you're looking at different databases, you can add a file to one database and refresh the view in the other. The only way to visually distinguish between these two two databases is by content.

Weirdness #2: no matter how hard you try, you can't open db2 from the Open SourceSafe Database dialog box because it isn't really a database.*   It doesn't have its own SRCSAFE.INI file.  Neither does it have its own set of user-specific SS.INI files.  One set of settings::multiple databases.

Weirdness #3: Open both db_template and db2 in separate instances of SourceSafe Explorer. Drag and drop a file from $(db_template)/ProjectA into $/(db2)/ProjectB. As I recall, this action appears to do something but does not actually do anything.  Next, drag $(db2)/ProjectA to a new ProjectC in db_template.  Doing so actually shares and branches ProjectA but not the version of ProjectA one would expect.  It shares and branches (or copies) $/(db_template)/ProjectA to $(db_template)/ProjectC!

*The source of all of this odd behavior is this: when you copied the \Data directory from db_template in steps 3 and 4, a new database identifier was not created. Both db_template and db2 think they're the same database.

In conclusion, this hack can result in some stranger than strange behavior. That's why I call it a stupid VSS trick and note that it has been"officially deprecated".  Stay tuned for more unnatural VSS acts in future posts and run Analyze on your favorite VSS database today.  Your database will thank you.

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.