Tuesday, January 13, 2009

Daily Git Tips, and what the hell, why don't I ramble about source control for a while

Gitready features daily tips for using the greener grass of Git. I like daily tips, they are easy to digest.

I'm really itching to try out Git in a project. The benefits of it as I understand them is Git is a distributed source control tool that is designed around easy branching and merging. I really should see if anyone's compiled a set of reason's why they think Git is better than x. I've read that Git's performance is competitive with other source control tools out there.

The idea of a trivial branch is very attractive to me. One area that I would love to see a branch in my own development practices is right before I commit a set of files. The one bug that seems to bite me the worst is when I have a set of files ready to be committed and I overlook one. My local unit tests won't pick up the omission because the overlooked file is on my system. It isn't until either the continuous build server finds the missing file or one of my colleagues finds the missing file that I must contritely fix the issue. If I could quickly create a branch, a commit branch if you will, that consists of the files that I'm ready to commit and the main branch that I'm working on I can run tests against that commit branch and verify that I'm not going to mess anything up. I think that would be very nice.

Here are a few quick thoughts on the other source control tools that I've used.

CVS has been the source control tool that my current client uses and my two previous employers use. Before CVS, I worked for a company that uses HOLY CRAP! $4380 a year per seat! Aye, I think we would have preferred getting a $4380 raise and using something that was free! Clearcase.

I think each tool has its merits. CVS fits the budgetary constraints. It's also a mature and reliable platform. Chances are, you aren't going to use CVS in a clever new way that's going to get you in trouble. You may very well use CVS in a way that isn't so clever that will get you in trouble though, e.g., put more content and users on a server than it can handle.

Clearcase, I thought, was a pain in the butt to configure, but once it was set up it was a pretty nice tool. The learning curve was a little steeper than I prefer with my tools. The transition for me was difficult to digest for many reasons, I would say that Clearcase and the way that Clearcase was used then contributed equally to my harsh experience. My other criticism is probably not appropriate for the tool per se. Clearcase's performance wasn't great, however it was also managing close to 100,000 files over multiple branches and supporting multiple development facilities across the globe. Clearcase's ability to perform clearly was not a key consideration when the logistics of this company's concurrent distributed software development process was planned out.

I thought the way that Clearcase handled managing branches and merges is as good as I've seen any other source control tool. The administrators of that Clearcase server were able to configure it to help enforce software engineering policies--branches could be locked down to prevent accidental/unauthorized commits.

No comments: