I was chatting with a friend of mine the other day about version control and why it’s necessary. So I decided to throw together a few options and a little explanation about why its important.
I have been using version control in some form or another for many years. I started with CVS, then moved to Subversion (which I still use quite a bit), and now, as my latest post about Git GUI’s on the Mac suggests, I have moved to Git. The one thing that has been consistent across every single transition has been that I had some sort of remote code storage every time. During the CVS days, I used a CVS pserver and stored my code locally and remotely for safety (and ease of checkout/deployment). For subversion, I always stored my code locally and used an apache install somewhere with a WebDAV module to get at and deploy whatever code is necessary.
Ultimately I use remote code storage for 2 reasons, back up my existing code base (so I have it in more than one place) and to have a visualization of what is going on in your project. That visualization is handy to be used as a central consistent view for multiple people (unlike a personal client which can be different per user).
Now in my more experienced days, I have decided that Git is the best VCS (Version Control System) for me. Not only does it allow me to use branching in a way that makes sense (which is something that Subversion still doesn’t do), but there are remote code storage entities that satisfy my requirements exactly. I have a few requirements:
- Look good
- Allow me to deploy using your system (via Capistrano)
- Allow me to manage projects (ticketing, wiki, etc)
- Have access control (user levels, etc on a per project basis)
- Support my version control system of choice (Git)
So now the point of this post, what’s out there. I have essentially found 2 options and have already had experience with both:
Codaset:
Codaset is still in beta so everything that may or may not be wrong with it will definitely be getting better. I have a great appreciation for the aesthetics that Codaset has. I find the color easier to work with and look at than Github’s basically gray and white theme. It may not have a lot more color, but the little bit helps. And speaking to that colorization (is that even a word), the colorized diffs are fantastic. Although Github has colorized diff as well, I find the Codaset diff’s are much easier to read.
Another great feature of Codaset (back to the visuals) is the idea that you can change the color format of a file while viewing it to any number of different types. Perl files are displayed differently than Ruby files, etc. Since I, like many avid geeks, program in a whole mess of different languages, this is a handy feature to help your eyes settle on syntax.
Github:
Github has a neat advantage over Codaset called Gists. Gists are basically pasties except they are a repository unto themselves and are therefore forkable and versioned and everything else cool that version control allows. As Github is more mature, there are a few more features it has as well like blame (which is handy for seeing who did what to a file).
Conclusion:
In the end, I have a Github account that I occasionally use for Gists, but I ended up on Codaset. So if you haven’t seen it, check it out. Let me know what you think. If you prefer Github, let me know why. But if you’re like me and although you may not be the best at making things look nice, but you want your tools to look nice, then maybe Codaset is the tool for you.
