The Hidden Reflex Blog

Git and Trac, both got married very recently (at our setup ), and the newlywed couple are quite a charm to work with. It all started with the search for a version control tool which could be used now, with just four of us using it, and that would scale beautifully to hundreds and thousands of users. The version control system would be the groom. Meanwhile we were also in search for a perfect partner (the bride), an issue tracking system, that would gel with our choice of version control seamlessly.

To begin with, we all (at Hidden Reflex) were leaning towards a central repository setup. This bias was there as we all had years of experience using them. The first obvious candidate was CVS, the next being SVN. But we wanted things to be lean and fast. As Alok researched the pros and cons of various version control systems, I installed Bazaar on my system and started playing with it. Bazaar is a distributed version control system, developed by the Ubuntu community. On their web-pages, Bazaar mentioned that it supported the the distributed as well as central version control setup. We started getting curious, and it was almost decided that Bazaar would be the groom.

Bazaar has CVS/SVN like commands and was very easy to pick up. While we were testing Bazaar, other candidates were knocking at the door. After a lot of online research, we zeroed on two more choices: Mercurial and Git. By this point we had a pretty good grasp of distributed version control systems and their pros and cons. We still wanted the best of both worlds, a centralized repository to keep track of things, and every developer using a version control on their local machines. I’ll discuss the benefit of this setup later in this post. Meanwhile, Bazaar was starting to look good as it promised to integrate and work with the setup we wanted. CVS, SVN and the like were out of the race for being too bulky.

Then at home, on the weekend, I happened to try Git on my laptop. I was amazed at the speed of this stupid version control. It was 2 to 10 times faster than Bazaar. The installation was smooth, the usage seamless. I do not know why it is mentioned in version control comparisons that Git is complicated and lacks documentation. The command line tools itself guide you on how to go about things and the man pages have good content and adequate examples to get you going. Even the online resources are pretty much exhaustive.

The very next day, I headed to our office. Alok was happy to see me, as it was Sunday and he was feeling lonely ;). Well, I presented the advantages of Git over Bazaar to Alok and so we decided to include it into the list of would be grooms. Mercurial didn’t show many advantages over the final two contenders, hence it too was out of the race now. So the final showdown was between Git and Bazaar. The speed of Git made this lean guy look very handsome, Bazaar on the other hand had a pretty face. The next criteria was support for a central repository. Though Git did not have that feature explicitly, it came pretty naturally that we can always create a repository on our server and call it central. That’s it! What came to us naturally is described in this post from Linus Torvalds, the creator of Git. We happened to stumble upon his post while doing a last round of research after making the final choice. The post clarifies how and why Git can be used as a central repository. To summarize (well almost) the post from Linus ; “It’s how you view things. Git never says you cannot maintain a central repository. You can always call one of the repositories the central one, to which all developers push changes. Along with this Git provides version control on your local system as well. That is where the power of Git lies. It lets you decide the setup you want and the work-flow you desire. Apart from that, it’s blazing fast and provides a rich set of commands to make it the macho man.” Git, is not stupid at all :), he is that Mr. Perfect all girls are looking for.

Meanwhile, the search for a compatible bride, the issue/bug tracking system, was on. We all had used and knew Bugzilla, and knew how big and heavy it was. And Bugzilla was not a good name for a bride to be . After a lot of research, gazing over comparison charts, reading other users’ experiences and trying demos, we selected Trac. For Git it was love at first sight. Trac had that perfect figure (very light weight), was beautiful (easy and nice web-based UI) and powerful. Though the last quality is not what you’d look for in a bride, but Git liked that, and so did we.

Trac is highly configurable and happily accepted the Git repository (on our central server). It provides an extensive library of plugins to add that extra feature you need and online documentation is good. We didn’t have problems setting it up on our server. And yes, Trac works with multiple repositories,a very good feature to have in an issue tracking system. The command line tool, trac-admin, is simple but very powerful, allowing you to customize a lot of things viz. fields for tickets, permissions etc. We also got E-Mail notifications working in no time (just edit the self explanatory trac.ini file).

To reiterate, the setup we went for was a central issue tracking system with a central cum distributed version control system. A local version control is a big plus for the developers. After checking out the code from the central repository (as in our setup) on their local machines, they can create experimental branches locally to test out new features, without worrying about breaking anything; or use the power of version control to keep track of the changes they make without even being on the network. A distributed system also helps developers to work in a collaborative environment for effectively sharing their local code-base; sending patches; merging code locally before pushing to the central repository. To be a little grandiloquent: the possibilities are endless and exciting. This allows for more experimentation, better local testing and better shared development. The central repository works as usual: it is used as the main code-base where the tested revisions are checked in; it enables the accountability desired in a collaborative environment by keeping proper track of the different code-development phases. Trac on the other hand provides all the necessary features in a small package, a really nice bride and bug tracking system.

The honeymoon period is still on and we hope that the couple stays happy; like a fairy tale “…and they lived happily every after.”