With the arrival of the new Distributed Version Control Systems (DVCS) such as git and mercurial many are asking….what’s the point? Do I really need to switch to a new source control system again? I *just* learned subversion and now it’s all changing again!!!

Other people, like the famed Joel Spolsky, are more blunt:

Here’s the part where you’re just going to have to take my word for it.

Mercurial is better than Subversion.

It is a better way of working on source code with a team. It is a better way of working on source code by yourself.

It is just better.

Now, instead of just saying that Mercurial or Git are just better, I’m going to give you five good reasons why – in easy, scannable, lovable, blog format. So without further ado, let’s start with #1:

1) Offline Commits

Have you ever got your code to a point where you wanted to check it in, but didn’t want to break the build for everyone else? Maybe you’d just spent 10 hours refactoring and felt like you’d really made some progress, but didn’t quite want to publish your creation to the world. But it still would be nice to take a snapshot of it in source control.

What about when you’re on the road and want to do a little coding, only to realize you have no connectivity to your central svn server to do your commits.

Git solves both of these problems by using a local repository. That’s right you get your very own repository right on your machine. You make your commits to it, and only push to the master repo when ready.

2) Speed

Because most operations in git work off the local repository they are lightning fast.

Instead of connecting up to the server repository to see the history on a file, you just look on your own hard drive. These operations are an order of magnitude faster because there is no network latency to deal with.

Not to mention that git was written by Linus Torvaldus – the guy knows a thing or two about optimizing code.

3) Push to Multiple Repositories

Once you have local repository how you like it, you can then push it to as many other repositories as you want. This concept is brilliantly illustrated by Heroku – the rails in the cloud site.

To deploy to heroku (after some simple set-up), you simply call:

git push heroku master

And your code is automagically deployed to the cloud. Want to push the same code to a web source control site like github?

Fine (after some simple set-up), just call:

git push github master

Now you’ve pushed the same code to two repositories.

4) Stops .svn File Pollution

Have you ever copied a code folder to a server only to see many, many more folders and files going across then you expected? After a quick slap to the head you realized that all of the hidden .svn folders and files are getting copied across as well.

That’s right. You forgot to do an svn export to clean out the folders before copying them – Doh!

With git, you don’t have to worry about about all of your folders getting cluttered with hidden junk because it only adds a folder to your top-level directory in your source tree. The rest stay beautifully clean!

5) Branching is Fun Again

Raise your hand if you’ve ever created a branch in subversion, worked on it for months and then suffered mightily when you tried to merge it back in. I’d be amazed if you’d used subversion for any length of time and not encountered this problem.

Git elegantly solves this issue by focusing on changesets rather than revisions. You see while subversion tracks revision (or what the entire tree looks like at a given point in time), git is much smarter and instead tracks changesets which are all the little changes that each person has made.

So when it comes time to do a merge, git has a lot more information and can tell that the function was just moved, not that it’s a conflict.

Conclusion

So why hasn’t git taken over the world yet? Well, the biggest problem, in my not so humble opinion, is lack of a slick GUI windows client. Many windows developers, for better or worse, are used to working with a nice GUI for source control and going back to the command line just isn’t a viable option.

Once a suitable windows client exists, be prepared to hear a lot more about git. I predict it will infect the windows world in the same way it has the ruby and linux world. Just as we all jumped from VSS to svn, soon we’ll be jumping to git.

Recently, I integrated OpenID into the latest revision of the Cub Scout BragVest site and I think it’s truly the wave of the future. But, as of yet, it’s a highly underutilized technology so I wanted to give a brief overview of it here.

What is it?

The OpenID site has a good description to start with:

OpenID allows you to use an existing account to sign in to multiple websites, without needing to create new passwords. With OpenID, your password is only given to your identity provider, and that provider then confirms your identity to the websites you visit. Other than your provider, no website ever sees your password

So let’s unwrap this. In a nutshell, OpenID allows you to use your existing accounts at big sites (like Google, Yahoo, MySpace, Hotmail, Facebook and Twitter) to login to other sites. All without creating a new username and password.

You are simply redirected to the site of your choice to login and then securely redirected back to the original site with an authentication token. The original site never sees your password.

What Problem Does it Solve?

Imagine that you find a cool new site (like BragVest) and you want start tracking your cub scout achievements. But you don’t want to create yet another login and password. With OpenID you can login to that site using your existing account at Facebook or Google account. 

It also means that you instantly have an account at the new site. No need to go through a new account creation or email verification process. Pretty cool, huh?

How Do I Use It?

The simplest way to get started with OpenID is to use a widget like the one provided by RPX Now. It’s free for basic use and lets you choose up to six “providers” (Google, Yahoo, etc).

To get going, you just go to RPX now and create an account. Then they walk you through the following three steps:

1. Generate Widget Code: RPX provides you with the code for a simple iFrame that displays their widget inline on your page.  It’s used to let the user select their provider in a user-friendly format.
2. Receive Tokens: After the user has been authenticated on their favorite site, you will receive a token value. You use that token to make auth_info call and retrieve more data (email, username, etc) about the user. RPX provides you with sample code to do this in a variety of languages.
3. Choose Providers: On the RPX site, you can choose which providers (Yahoo, Facebook, Google, etc) that you’d like their widget to display.

After that, you’re done!  I’m hoping to see more sites start utilizing openID so I can stop having to remember so many usernames and passwords.