I've been a user of Microsoft Visual SourceSafe for a long time. Back in the days of VB5 and 6 it was the obvious choice and continued to be for the first few releases of Visual Studio .NET as well. In the typical environment at the time, it was easy to set up and had pretty good integration with the IDE.

I recently started a new project with a new client and was faced with establishing an adequate development environment. We have a two-member development team and the client doesn't currently have a place for us to sit onsite. We'll be using Visual Studio 2005 and 2008 for writing web applications, SSIS packages, and database changes.

Visual SourceSafe is no longer an obvious choice. First of all, Microsoft seems to want everyone to use Team System and forget that SourceSafe exists--I couldn't even find the SourceSafe setup on the Visual Studio install DVD and had to download it from the MSDN site. Team System is overkill for a two developer team (in my opinion it's probably too much for any team smaller than ten members) and would be more trouble than it's worth to set up in our environment, not to mention the cost.

Thinking through the SourceSafe scenario, it wasn't feeling right for our situation. We could install it on the client's file server but then we'd have to VPN in everytime we needed it. We could install it in web mode on the client's web server, but that comes with a whole other set of configuration issues and initial coordination with the client's overworked network administrator. We could install SourceSafe in web mode on one of our home PCs that's always on, but then we might run into upstream bandwidth limitations on our cable modems.

So I started looking at alternatives. Our requirements are ease of setup; works well in a distributed, often disconnected environment; reasonable performance; works well with Visual Studio projects; and low cost.

After following a chain of several possibilities, the product that stood out was the open source product Git. Git meets every one of our requirements well--it allows developers to work locally and independently, syncing with the master repository when they can (and want to); it installs pretty painlessly even on Windows; it's super fast; and it's free. As a bonus, it may be the most powerful source code control system out there.

The next decision was where to host the repository. We could do it on the client's web server, but then we have to mess with configuring the protocol of our choice (SSH, WebDAV, or Git's own). We could install it on one of our home PCs but again, we'd have to mess with configurations and router settings. Putting the master repository on one of our laptops (which we are using for development) probably won't work because we won't have them on all the time and our IP addresses won't be stable. So, I started exploring potential hosting sites. There are some free ones, but most of them require you to open source your work, which wasn't going to fly with this proprietary client project. Some offer a variety of hosting plans, most of which you either pay too much for or outgrow quickly. In the end, I settled on RepositoryHosting.com, which offers a single hosting plan of unlimited projects and users and 2 GB of space for $6 per month. They have 30 day free trial, so I figured we'd give it a try. So far it's worked out great.

The hardest part about this process has been the learning curve with Git. Its concepts and way of working are quite different from the way things are in the SourceSafe world. The whole time I was learning it, I was wishing I could just have a handy guide mapping SourceSafe features and concepts to the Git equivalent. So the purpose of this article is to help people like me, veteran SourceSafe users, migrate to the world of Git.

I won't detail the installation instructions here since they are covered elsewhere and are subject to change. Just know that yes, Git works under Windows, has a GUI version, and works well with Visual Studio (the integration isn't spectacular, but as you'll see, it doesn't really matter).

The first thing that I couldn't understand was where my working directory was. In SourceSafe we have a central database on a server somewhere and then each developer has a working directory where their working copy of the files reside. With Git, every developer has their own copy of the source control database (called the repository in Git terms). That may seem inefficient, but it has lots of benefits including performance, flexibility, and redundancy (it's always nice to have one more place you can restore from). Each developer's Git repository is stored directly under their working directory in a .git folder. So when you add your project to Git for the first time, Git adds a .git folder in your project directory to hold the repository for that project. 

Once I got everything into Git, I figured I needed to check out some files to work on. Well, there isn't really a checkout in Git. You just work on what you need to work on and it'll help you sort it all out later. It's a lot simpler than you might be thinking! With Git, there are no more issues of not being able to work on a file because some other developer has it checked out and no more problems with developers who forget to checkin their files before they go on vacation! Just go ahead and make your changes.

In the SourceSafe world, when you're done with a batch of changes and are ready to check-in your work, you select the files you changed and perform a check-in. Git adds a level here called staging, which is the set of files you plan to check-in the next time you do a check-in. Seems like extra work, but it's actually handy. First, Git makes it easy by automatically telling you which files have been changed. Using staging, you have the flexibility to decide which of those files (perhaps all of them) should be used for your next check-in. Once you have everything staged for the check-in, you perform the check-in, at which point you supply a comment and an optional tag. By the way, if you don't want that extra staging step, you can move directly from modified to committed using the command-line version of Git, but I don't think the GUI supports this.

Here's the tricky part to understand: what we just committed still only resides in our private copy of the repository. To get it shared with the rest of the development team, we have to talk about remote repositories. This is where the hosting site comes in (of course you can install it on one of your corporate servers, or you can even use Git in a purely distributed fashion where rather than using a central repository every developer connects to every other developer). The central repository holds the "official", shared copy of the source code. Usually this gets set up by the developer who creates the project initially--after adding the project to his local Git repository he then "pushes" it to a new remote repository. Then, the other developers initialize their local repositories by "cloning" the remote repository.

Once the remote repository is set up (quite easy), as each developer does check-ins on their own machine, they can decide at certain points to share their commits with the rest of the team. This is done with a "push" to the remote repository. As you might expect, this is where it can get interesting when developers are all pushing changes to the same project willy-nilly. But it's no problem! You can bring the changes that exist in the remote repository down to your local repository using a "fetch" command. In most cases, this works very smoothly and quickly. If however, the changes coming down conflict with work you've already done (because you and another developer modified the same lines of code), you get a merge conflict. Thankfully, the Git GUI makes it easy to identify the conflict and choose the proper version (or combine them).

Most smaller development teams don't mess much with branching in source control systems, and that's partly because the tools always made it difficult. But this is one of Git's strong points, and it's so liberating to now be able to create branches when I want to work on little side enhancements or experimental features and know that it'll be easy to merge it all together when I'm ready (or scrap what I've done). And with Git, it's now so easy to switch over to fixing an emergency problem with the production version even though we're in the middle of testing the next version and developing the one after that, and we can get back to what we were working on with just one or two commands!

I mentioned earlier that Git provides integration with Visual Studio. You'll need to install the Git Extensions, which adds a toolbar to Visual Studio 2005 and 2008 and also provides optional shell integration (so you can right-click in Explorer to checkin/out, etc.). Git doesn't have the same fancy file status indicators in Visual Studio that SourceSafe provides, but since you don't need to check files out to work on them, it really doesn't matter. So far, I've found the Git GUI does everything I need without finding much use for the Visual Studio integration.

A user's guide for Git is available on the download site and it also provides a full set of local man(ual) pages. But the best material for learning Git is the Apress book Pro Git by Scott Chacon which is available in hardcopy at all the usual places and online for free.

There was one other pleasant surprise in this quest for a new vcs. I was also looking for a way to track bugs, feature requests, tasks, etc. In the past I've used Axosoft's OnTime and I'm a fan of their product. I've also heard good things about FogBugz. But both of those products are fairly expensive for a small team. Well, it turns out the $6/month plan at RepositoryHosting also includes Trac, an open source issue management system. So far, it seems to more than meet our needs, and it integrates with Git, so we can map code check-ins to the bugs they fix and features they implement.

The bottom line recommendation: regardless of your team size, make the switch from Visual SouceSafe to Git the next time you get a chance. 

Comments (0)

Subscribe to this comment's feed

Show/hide comments

Show/hide comment form

Name

Email

Website

Title

Comment

smaller | bigger

Subscribe via email (registered users only)

I have read and agree to the Terms of Usage.

Add Comment