Living the startup life in Atlanta, GA.

On Friday I had lunch with the founder and CEO of Return7, Amro Mousa.  The discussion of course covered the state of iPhone development and what makes money on the App Store. Sure there are some folks putting deposits on Ferraris because they built super useful or fun apps. But there are other’s in the Ferrari dealership because they made something like iFart or SoundGrenade. Apps that don’t really do anything, but are cheap and appeal to sophomoric sensibilities.

Amro spent some time soliciting stupid app ideas. It wasn’t until later that the realization that these aren’t dumb app ideas. These ideas are brilliant.

Fart apps and their ilk were simply too hard in the past. First, there are technical hurdles. Any mobile platforms do not allow speakerphone access from an application. A desktop version is too bulky for an effective prank.

Then there’s distribution. If someone pranked me with such an app, there would be significant effort involved obtaining the app for a counter attack. The App Store makes it easy to get revenge, adding to the app’s viral nature.

Finally, the cost-benefit analysis is crystal clear. I know what the app does. It’s a dollar and it makes a fart sound. If that floats my boat, I get it, otherwise I pass. Simple and without the hidden cost of a time investment.

Which is why these ideas are brilliant, they created something that did not exist in the market place before. The vast majority of useful apps are a variation of “something that I use, but mobile.” There are two problems with these apps. First, most apps that are useful that I should be using a lot, I simply don’t. Pandora, RememberTheMilk, Mint, etc are all great, but I simply don’t check them enough. Second, I, like most folks I know, are near a computer almost every waking hour of the day.

I don’t really need a mobile version of the apps I’m not using. I would pay for a mobile version of an app that I never had before. The road to riches on the App Store is figuring out what that is.

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