CVS for SourceSafe users

I used SourceSafe for probably 8 years as a revision control system with Microsoft Visual Studio.  I didn’t switch to CVS by choice – I started working for a company where most of the other developers came from a Unix background, and they’d been using CVS for years, even to store their Windows-only projects.

 

This took some getting used to.  SourceSafe is a good solution for a single developer or small number of developers on a LAN, since it’s integration with Microsoft Visual Studio makes it very easy to manage your source code.  But SourceSafe has it’s limitations:


  • It’s very slow over VPN connections.  I believe this is because it uses file system level access to the revision control database, and this means lots of protocol overhead.  Latency kills SourceSafe.
  • It requires file system access to the repository.  There is no SourceSafe server process, meaning that when you want to save your updated source code into the repository, your computer is directly updating the repository files.  If your computer crashes in the middle of this operation, bad things can happen to the database – definitely a bad design for something as important as the database containing your source code.

This short article is just a conceptual comparison between CVS and SourceSafe, from the perspective of a SourceSafe user trying to figure out CVS.  Here are some of the key differences:


  • CVS has a server. To get files from a CVS repository (that’s the equivalent term to a SourceSafe database), you’ll need to know the server name, your login info, and the path to the repository on the server.
  • Typically, with CVS, you don’t check a file out before working on it.  This takes some getting used to. With SourceSafe, you explicitly check files out before you modify them, and anyone else can see that you have those files checked out; with CVS, you simply start working on your local copy of the files, and when you’re done with them, you “commit” your changes.  The commit action makes sure that your local copy is in sync with the one on the server; if they’re not, it will ask you to “update“ first.  (Update is roughly equivalent to SourceSafe’s Get, and it will merge changes from the server into your local version if you’ve modified it).
  • Some operations are two-step operations.  For example, if you want to add new files to the repository, you have to add them, and then commit them.

There are many CVS clients for Windows, from a basic command line to a GUI (WinCVS) that works somewhat like the SourceSafe GUI, to the one I personally prefer, TortoiseCVS, which works as an Windows Explorer extension, showing coloured overlays to indicate the status of files (green means your working copy is current, red means your working copy conflicts with changes in the repository, etc).