Partager via

An Advantage for SourceSafe over Team Foundation Server

  • Article

Having worked with Visual SourceSafe (VSS) since the mid-90s, first as a developer working at an ISV and then for the last seven years as a consultant at Microsoft, I have grown quite fond of this application. SourceSafe has always been there for me when I have needed a Source Control System (SCS) and it's easily integrated with Visual Studio. But now that Team Foundation Server (TFS) has been released along with its new and improved SCS everything has gotten much better, or has it?

I'd like to discuss the only real advantage that VSS has over TFS: VSS can be deployed on your local development machine.

VSS is not a server application, it consists of a directory structure which contains 100s or 1000s of files which makes up your repository of the source control system. A VSS client runs locally on the developers machine and performs direct access to the files in the directory structure. In most cases this directory structure is located on a network share which allow multiple developers to work against a the same source control system. But when experimenting with source control techniques or working on a local project it can be useful to have the files on your local disk to be able to run completely offline from other systems.

TFS on the other hand stores all information in SQL Server and uses web services hosted on a server to provide access to the information in the source control system. When a client works against TFS it actually works against the web service and not directly against the data store in the database. The problem with TFS (from the perspective of this post) is that it requires Windows Server 2003 to install. Most of the core functionality would be possible to run on XP/Vista (SQL Server and web services) but it is not possible to try this as the setup program terminates unless you have Windows SharePoint Services (WSSS) installed (which requires Windows Server 2003).

To me this presents a problem. I'm running Vista and have Visual Studio, SQL Server, BizTalk Server, etc. running locally but I cannot get TFS to install. This means that when I perform small assignments for customers I still need to use VSS to keep track of my changes. Perhaps TFS is not really targeted at the small project size that a one-man-show represents, but I would still like to use the featureset of TFS on my local machine, just as I run BizTalk Server on my machine for development purposes. For experiments I use Virtual Server, but I don't like virtual environments for pure development...

So I guess the conclusion is that even though TFS improves the development experience for most types of teams, a team of one is not really a priority for TFS. So a single-user, single-machine scenario can in many cases be better supported using VSS.

Comments

  • Anonymous
    October 23, 2006
    Nothing against VSS (hey, we have both the original authors and the current owners in our office here in NC!), but a couple of quick notes: If the teams are that small (1 or 2 people), it's worth noting that there's no need for it to be a physical TFS install.  I've run across a good number of people running TFS in a VPC (you can even download a pre-done VPC image from MSDN!) and then using that as their server (running on the same laptop/desktop they develop on).

  • Anonymous
    October 23, 2006
    The comment has been removed