Saturday, May 23, 2009

The evolution of SCM or Why I would like any teams I'm on to use Git

Back in the olden days of Source Code Management (SCM) there was SCCS and the original Unix things. These depended on developers checking out code with a LOCK. Because, after all, if you didn't have a lock and you changed things, badness would follow.

Well, then along came CVS and out went the idea of locking. Why? Merging became easy - in fact CVS would do it for you. Ok sure, sometimes there are conflicts and you have to merge yourself... but in fact, this is rare (at least for small to medium teams I've been on).

So then we upgraded to Subversion - not really substantially different than CVS - still lock-free central repository.

In this world (at least on the projects I've been on) you always check in against the trunk - i.e. the main line of code. Branching the code is still icky and to be avoided.

Now, along comes Git. (N.B. this discussion may apply to Mercurial also, i have no experience with that, but I know it's popular in many Java (i.e. Snoracle) circles). I don't have tons of experience with Git yet, and I may have forgotten the wonderful things the guys from came over to @iVolunteer to teach us ( - BUT I'm convinced of the Git-goodness!

There are two basic revolutionary aspects to it, from what I can tell:
1) no central repository. In some sense you use convention over configuration to determine who has the "central repository". Yes, you need to take backups somewhere. Yes, you need to figure out which repository to check out from for doing a build. However, the good news is that this can be *anybody* "in the network". Because everybody has a copy of the whole history (more or less), *anybody* can do the build.
2) local repository. This means several things, not the least of which is that if you're developing code you can check in locally and not break the build. How does that work? You have the whole repository. But what about everybody else's code? You have all the history you've requested from them. If you haven't "pulled" from their local repository, yes, you're hosed. So pull it and then do a build. Or have them pull from you and do a build - it just doesn't matter - and that's the beauty of it. So just as CVS got rid of the notion of merging being hard, Git gets rid of the notion that branching is hard.

Variations on a theme:
- sure, it's nice to have a publicly accessible, backed up, repository. That's where Github comes in (and presumably whereever you want to install the equivalent. But wait, doesn't that make it just like SVN? Well, ok - yes, to some degree.
- there is much finer granularity of changes. because you can check in locally, and then I can pull from you, I can't get changes from someone that I might want to integrate with before (possilby) screwing up the whole thing.
- and even finer, (this may be a GitX thing) you can check in just *some* changes to a file. I had occasion where I changed a properties file (IIRC) and wanted to check in the new properties, but NOT the hard coded path to my specific files. I checked in just some of the changes to the file - sweet.

now back to figuring out how to update and check in...