Living the startup life in Atlanta, GA.

I’ve already posted about why I like Git better than Subversion. This motivated me to install the GIT-SVN bridge up to my work SVN repository.

Using the bridge is a bit confusing at first. This tweet by Calvin Yu pointed out is right on the money. Git’s interface isn’t great, but it is powerful. There are two major resources that I use to use the bridge effectively: this blog post and the git-svn man page which has a lot of examples. Between the two, I’ve been able to do almost everything I want.

So why go through the effort of cloning your SVN repository (which took a half day for me)? What follows are my reasons.

Local Branching

We’ve got a fairly large development team. If we let encourage every developer to create a branch for each whim, our branch space would be quickly polluted. Since most of the exploratory work is generally done by one person, there isn’t any real need for collaboration either. The end result is work that often just disappears as developers find it hard to maintain a lot of uncommitted changes.

Git allows you to create local branches. These branches exist within your repository. You can commit to them as often as you like.

Fast Branch Switching

Git is a clone of your whole repository. Most importantly, it’s an efficient clone of the whole repository. Which means you only have to download deltas when you change branches. If you need to work on a new branch in SVN, you need to check the whole thing out. On a sizable repository hosted off-site, this can take a while.

Recently, I was working on a local branch. I needed something from the head of another branch, so I checked that out and did what I needed to do. Then I got an email from my boss asking me to look at a bug. I checked out trunk. It was an easy fix and shortly thereafter, I got another email asking me to commit it to the release branch, a branch that I’ve never checked out. I checked it out and committed it there too. With git-svn, this whole process took 20 minutes, including the time to fix the bug. Given that each branch is nearly half a gig, and our outside line isn’t very fast, that’s pretty impressive.

Cherry Pick

Git has a command that pulls a single commit from one branch to any other branch. Sure you can do the same thing with SVN merge, but nobody remembers that syntax.

Local Commits

It’s really nice to be able to occasionally commit intermediary code without breaking the build. When I make a mistake or can’t figure out why something that was working isn’t anymore, having past versions to look at is helpful.

The Stash

Occasionally you have to switch gears. Git Stash lets you do that without losing work.

Being Trendy

Hey, style is important too Seriously, the benefits outlined above, though simple, can save a massive amount of time when things are breaking all over the place. That alone is causing the use of the bridge to slowly spread through the organization.

Sonali and I have been working a project to make a light weight and hosted project management tool. We’re calling it SCMPLE and yesterday was our first pitch. You can checkout Our Slides.

For those that don’t know, Startup Riot gives startups like ours a forum to present and connect with like minded individuals. We’re barely out of the idea stage, but we still had a bunch of people come up and talk to us about our idea. Which rocked, because we were the second up and I wasn’t all that awake yet.

There wasn’t very much that didn’t rock about the event. Given that we’re pitching a Git based idea, I would have preferred to have not immediately followed the keynote by Chris Wanswrath of GitHub fame. He gave a great talk, has a very cool product, and is a super nice guy, so it’s hard to be upset about that. The overall message of “do what you’re passionate about” resonated strongly within the audience.

The pitches were surprisingly interesting. You’d think that watching 17 or so companies present in a row would get boring or repetitive, but neither happened. Even the bad pitches or unreadable slides were worthwhile because of the Backnoise, though it did go a little overboard.

The only real downside of StartupRiot is that I’ve had to switch to TweetDeck. Just met enough new folks to break the camel’s back with Hahlo.

As a presenter, I’ve got to thank Sanjay Parekh, not just for the main event, but all the free advice and help in getting ready for it. It was my first pitch out to an audience that didn’t know exactly what I was talking about. I also need to thank Scott Burkett and Jeff McConnell, who both gave some great guidance during the practice session.

Also as a presenter, I wouldn’t mind paying to present. The fees for StartupRiot really are nominal, given the value I obtained for it. If there is anything that will keep the event going, I’m all for it.

SVN is based on a relic and broken. A fundamental feature of SVN/CVS is that one’s working copy is a subtree of the repository. At some point in the distant past, this made sense. Diskspace and bandwidth were limited and expensive, but times have changed for the better. However, the design and functionality of CVS stems from this core feature. SVN is a major improvement over CVS by including atomic commits, better support for binary files, and using deltas to create branches (making branching and tagging cheap), but it’s still tied to the partial working directory concept.

For an example of why this sucks, checkout some code with SVN. Then do a rm -rf on a directory, followed by a svn status . Hilarity will ensue.

I want my version control to be as out of the way as possible. I don’t want hidden directories everywhere. I don’t want to svn delete, followed by a commit, followed by pulling out the SVN Manual and scracthing my head. I just want to remove the directory. The version control tool should deal. It works for me, not the other way around.

It’s a little thing, but it got under my skin enough to find another solution. I’ve started using Git for all of my personal projects and become a big fan of the tool. Now that I’ve gotten the ranting out of the way, what follows are what I see as the benefits.

*** CAVEAT *** If you want a tool that works like SVN, use SVN. Git is not for you.

The biggest difference between Git and SVN is that Git is distributed version control. Every working copy is full clone of the repository. SVN is hosted on a single server. An SVN working copy is just the current checked out code: nothing more, nothing less.

Distributed version control is a little more complicated, but it gives the user a lot of flexibility. I can start working on a project and version control it on my laptop immediately. When it comes time to share, setting up a hosted repository is trivial, or I can use a site like GitHub to host it for me.

Since I have a local repository I can freely check stuff in without worrying about its impact on other developers. If I do something that I know is going to break IE, or if I haven’t finished my unit tests, I can still commit code so that I can rolllback after the inevitable screw up. However, I don’t have to make the code public until everything is done. It’s like the local history feature in Eclipse, but you don’t need 6Gigs of RAM and a JVM.

Also, since it’s distributed, you can model usage to your team structure. SVN forces you into a situation where you are basically treating your committers as an organized whole, like a development team in a company. Git’s processes were designed to be the version control tool for the Linux kernel. Git is designed to work well with patchsets. Or you can have the team leader responsible for pulling finished code from team member’s trees. Or you can use it (almost) like you would SVN.

The other major benefit of Git is the command line tools are a lot better. git status gives more information than svn status. Most of the tools work on directories as well as files. git log is super flexible and can give you extremely detailed reports.

Obviously, this isn’t an indepth article. These are just the reasons that I keep using Git. Git is not perfect and there are some drawbacks, but I think it’s the best free version control system. Finally, if you are interested in Git, here are a few things to keep in mind to get over the initial frustrations and learning curve:

• Don’t be afraid of committing, there’s no risk
• Everything in Git happens to to the head of your repository branch. This means merges, updates, etc, occur against what you’ve checked in locally
• Always check in before pulling from a remote repository
• You have to pull before you can push to a remote repository
• Git is less intuitive than SVN, but it’s easier to use
• Git is not SVN
• Most operations work on directories
• The GUI tools suck
• The docs were written by the same guys that think man pages are intuitive

When working on Appcelerator’s AppEngine support, I needed to find some API documentation for Beaker. I didn’t find it, but I did find this gem.

This guy can’t figure out why companies (or individual developers) would ever pay money for a hosted DVCS repository. The great thing about DVCS is that you don’t need a centralized repository. Unfortunately, this independence from centralization goes away once you have to give your software to somebody. At that point, one repository becomes the master. You could just go round-robin and pick the source off one of the developer’s boxes. You could also jump out of an airplane without a parachute. Just because you can do it doesn’t mean it’s a good idea.

Which leaves you with two options:

Option one is fight with budgeting to get a box to hold the repository. Since it probably has to be somewhat beefy, it probably just can’t come out of the normal budget. This means you talk to budgeting. Once you get the box, you need to install the software on it and connect it to the network. So now the IT department is involved. Get a developer to write a script to back up the repository regularly. Bring in the development department. Find a place to back up the repository. Figure out some way for developers to push and pull code to the master from off-site (often this means you have to poke a hole through a firewall). In a small company, that’s all one person, and the whole process takes a few hours. In a larger company, that’s three different departments, which means conference calls, emails, arguments, angst, internal billing negotiations, and a process that could take anywhere from a week to years.

Or you can pay $100/mo and not have to deal with any of it. If you’re a development manager, how would you choose?

Ben goes on to claim that this type of software-as-a-service silliness is endemic of Rails apps as is having good design. As someone who has to do more than work on Open-Source Python server code, it’s very obvious why people use these services. They are more benefit than cost. The developers put thought into the experience and it doesn’t hurt your eyes when you look at it *cough* trac *cough*. People appreciate that effort and will pay for that. Otherwise, Apple would be out of business and the iPod would have been a flop.

I like Python as a language. I’m likely to use it for my own stuff someday. However, the reason Rails became more popular, although it’s a relative late-comer, is that the creators of Rails thought about the user experience. The point is that they were designers and not pure developers. They understood that design is not just decoration. They focused on making something that was useful to somebody. Repeating that thought process isn’t copy-and-paste, it’s good sense.