I was never a big fan of distributed source code management – I was perfectly happy delivering our projects through Subversion. Then, shortly after ourTransDrive project was completed, we went to the 2009 Qt Developer Days conference and my opinions changed. Our client asked for some last minute changes and what followed was no surprise – Murphy’s law taught me something the hard way.
My source code was out of sync on my laptop, and, due to high US data roaming rates, I could not tether to sync it with the main server. We went straight to our flight where I spent several hours being less productive than I would have liked. On the second day of the conference, the Internet connection flaked out and I could not sync with the main server; once again, I was not as productive as I could have been.
When we returned from the trip I promptly started researching distributed source code management (DSCM). What I learnt from my research is this: All the main DSCM applications are more-or-less the same and the differences that do exist are more important to the developer’s workflow than the application’s technical merit. While we love and use Python regularly, out of Mercurial and git we went with the latter. After much reading and testing gitand Mercurial we eventually settled on git for a few reasons:
- Used by projects we are heavily dependant on: Qt and Linux;
- Branching and merging techniques align with our workflow;
- Great Linux and OS X support;
- Very good Subversion integration.
For me, the second and last points were key. The branching and merging in git worked according to my beliefs and workflow and was therefore a natural transition for me. The last point is important because we need to continue work on TransDrive and thus integrate with Subversion.
The take away points here are: Expect the best but prepare for the worst – don’t let technical issues block your business. The second point is to go with what’s right for you – don’t decide on software because of trivial technical differences.