Visual SourceSafe

There is currently no direct migration recipe for VSS repositories. The suggested approach is to:

  1. Convert from VSS to Subversion using VSSMigrate or vss2svn, or PolarionImporter.
  • vss2svn processes the backend VSS database and does not require VSS itself
  • Most of the other solutions require the VSS program
  1. Migrate the data from Subversion to Bazaar.

Most of the solutions require the Visual SourceSafe “SS.exe” program to operate, except vss2svn. There is a COM API for VSS but it doesn’t expose all the features, so dependent tools parse the output of SS.exe. Even SS.exe doesn’t allow you to retrieve all the data, as you can’t retrieve deleted or renamed files, so vss2svn would seem to be the most thorough solution.

As it processes the backend database, vss2svn would be the best candidate for porting to a vss-fast-export, but bear in mind that most of these projects are very mature ; vss2svn seems to be the most active and the source hasn’t been touched in a year.

All the solutions seem to suffer from locale issues. The output of SS.exe is localized. All utils suffer from the fact that VSS uses the path encoding of the client, so paths can have a mixture of encodings.

Project Issues

Some of the content kept within VSS may have depended on some of the features of VSS to work correctly.

Shared Files

VSS provides a “Share File” feature - this essentially replicates the common POSIX soft link feature within the VSS filesystem, but not on the Windows file system where the shared files are just copies. Shared files are updated to the latest version by VSS (unless they are Pinned) in each location they are shared. Projects that use shared files may start to miss this behaviour once migrated to Bazaar, since the shared files will simply be copied by most migration software, causing them to have their own history and independant existence.

Visual Studio does support linking to files via a relative path, so you could migrate the files to a single common folder within your tree, perhaps at the root level beside the other projects, and use the Visual Studio link feature instead of the VSS link feature.

rather than

$\project\MyProject.vbp              # I'm the project file and I include ErrorHandler\Handler.bas
         \ErrorHandler\Handler.bas   # I am a Shared file

instead

$\project\MyProject.vbp              # I would link to ..\lib\ErrorHandler\Handler.bas
$\lib\ErrorHandler\Handler.bas

Newer versions of Windows (Vista and above) do support POSIX-like linking semantics in the file system, but as yet, Bazaar does not exploit them. When and if it does, real filesystem links could replicate this feature.

Alternately, you might want to consider building these shared files into a separate library and referencing that from your project instead, where possible.

Pinned Shared Files

VSS supports the notion of “Pin” on shared files - this fixes the shared file at a given version and stops it being updated by VSS when the master “Shared” file is changed.

This is a form of branching. If you have pinned library files, you might want to think about breaking the libraries out into a separate Bazaar tree and creating a branch for each pinned version you require.

Table Of Contents

Previous topic

CVS

Next topic

ClearCase

This Page