I’ve seen this question asked a couple of times, so I thought it might be time to write a blog entry to have people to point to when I’ll see it again…
Let me start by saying there are no database format changes between VSS6.0 and VSS2005, thus there is no need to convert the database (like it was the case with previous versions). VSS 6.0 can use a database created with VSS 2005, and vice versa (and only VSS2005 will benefit from new features like checkout local version, time zones, etc).
There are two possible migration paths:
a) Want to upgrade from VSS 6.0 to VSS 2005 on the same machine
Since there is no database conversion required, all you need to do is to install VSS 2005. You may install VSS6 and VSS2005 side by side if you want to test the new bits, but should you decide to uninstall VSS6 you will need to repair your VSS2005 installation (or reinstall it).
I recommend uninstalling first VSS 6.0. The uninstall will not delete existing VSS databases on the machine. After that, simply install VSS 2005. If you do it in this order, all the VSS binaries (ssapi.dll, ssscc.dll) will remain registered correctly, and you should be able to just open VSS2005 and have things working as before.
b) Have a machine with VSS 6.0 but want to setup a new server with VSS2005
Start by setting up the new server machine (install OS, etc.), install IIS if you need to use the database with FrontPage or plan to use VSS remote.
Install VSS2005 on the new machine. VSS2005 does not create a new database on setup, like it was the case with VSS6.0.
A VSS database is comprised by a couple of files on a network share. You will have to copy the VSS databases from the existing machine onto the new machine. Identify the VSS database folders on the old machine. Make sure there are no users still accessing the old database (a good way to do this is to disconnect/remove the network shares on the old machine). Copy the database folder into a new folder on the new machine. Any recursive copy command can be used (xcopy /s, robocopy /mir, WindowsExplorer, etc). On the new machine, share the database folder.
If you’ve been using the VSS database with FrontPage Server Extensions, you’ll need to write a registry key on the new machine. The VSS2005 installer can’t write this key for you like VSS6 did, because it does not create a new database during setup.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SourceSafe]
“API Current Database”=”Path to the database on the new machine”
Have all other VSS database users uninstall their VSS 6.0 and install VSS2005. While the database can be used in a mixed client environment, it’s recommended that all clients use VSS2005 to benefit of the new features and avoid inconveniences (e.g. VSS6 users won’t be able to merge UTF8 or Unicode files checked in with VSS2005).
Communicate the new database path to all all other team members and have them open the new VSS database by pointing VSS Explorer to the new database.
You may also want now to consider using the new features of VSS 2005. E.g In SSAdmin, Tools/Options/General page consider whether you want to enable CheckoutLocalVersion, set a time zone for the database in the TimeZones tab, use Server/Configure dialog and decide whether you will use this database for remote access or want to configure the LAN service for better performance on LAN, etc.