The DVCS Wars

August 02, 2009 at 02:42 AM | categories: dvcs, mercurial, git | View Comments

What is it about us nerds that dictates every discussion must be a war of some description? It isn't enough that we have two (or more) great technologies at our disposal, we also have to fight about it and of-course we have to be right. For example the age-old conflict between Vi and Emacs seems to continue today, as passionately as ever. And why not? There's nothing like a good ol' fashioned flame war to get the blood pumping.

This post, in all fairness, should really be called "Why I switched from Mercurial to Git". I actually quite like Mercurial and it was the original DVCS that opened my eyes to a world beyond SVN. Upon first hearing about the exciting concept of DVCS I knew that I needed to get my hands on one ASAP. But of course it couldn't just be any DVCS, it had to be the best one. So I did some more reading, scoured blogs for any material I could find on the topic so I could make the perfect choice. And I did. Only I picked the wrong perfect one...

Mercurial has so many good things going for it. The command line is clean and simple, and for SVN escapees feels very much like home. It's written in Python, which helps on Windows, and has a nice plugin architecture. In addition it has a good balance of speed and size, not requiring any silly garbage collection. Oh how I used to laugh at those poor Git fools, why couldn't they see the folly of their ways. So what changed? I guess curiosity got the better of me. I read one too many pro-Git articles and realised I might just be missing something.

What makes Git worth switching too then? In short, the repository format. Everything else, in my opinion, is just porcelain. The defining moment for me was when I learnt about reflog. So anything I commit is safely backed-up for 90 days regardless of what I do to the visible history? Count me in!

The safety net of Git's repository format in this respect is liberating. Commands like rebase are not so much 'modifying history' as modifying your view of history, because you can always retrieve the old version (within 90 days) if you need it again. On the other hand when you modify the history in Mercurial you really are modifying the history. Whoops you've just stripped that commit from your repository; I hope you made a backup. This is one of those fundamental differences between Git and Mercurial, carefully considered and implemented by their original designers. It means that in Git you have the trade-off of having to run a gc occasionally to remove those pesky unused objects. I'm cool with that if it means I get my reflog and a rebase that is 100% refundable, no questions asked. I should hastily add that I've never 'lost' a commit and I'm certainly not trying to suggest that Mercurial is unsafe. For me personally it's about that extra layer of comfort and freedom that Git provides.

After that everything else seemed to just fall into place. I'd never really liked Mercurial's (previous) answer to local branches: MQ. Having to learn a whole new set of commands to essentially do the same thing. I kept forgetting which 'q' command did what. Why should I even have to remember different commands, why can't I just commit and rebase later? Of course I'm being simplistic here, and MQ is a very powerful tool, but what I really wanted was a way to work as normal and decide later how to sync my changes.

I find something strangely fascinating about version control, and I don't think I'm the only one either. It seems to be a topic that draws an unusual amount of attention, much to the continual annoyance of their creators I'm sure. Like everything in life, there is no absolute right or wrong in regards to version control, as much as we'd like to argue there is [1]. What is perfect for someone may be hell for another. Many people have happily switched from Git to Mercurial, and while I think they're crazy I think I understand why. My rookie mistake was not playing with all the alternatives in the beginning. Git has turned out to be the ideal tool for me; it compliments the way I work and think in a way that Mercurial didn't or can't by design.

[1] Unless of course you prefer Clearcase, in which case you're ugly and stupid. :-P
Read and Post Comments

ClearCase strikes back

July 12, 2009 at 01:57 AM | categories: svn, git, java, python, dvcs, linux, clearcase | View Comments

So it's been almost a year since my last post and I obviously haven't had much to say. I'm back to talk about the exact same thing, again. I really need to find something other than version control to obsess about...

Recently I made the switch to Ubuntu at work. This left me without ClearCase, as it requires some derivative of enterprise Redhat or SUSE, which didn't interest me in the slightest. I can only assume this is partially due to the complexities of managing a separate binary kernel module required by MVFS, their virtual filesystem. As an alternative Rational seem to be pushing their Java implementation ClearCase Remote Client (CCRC). CCRC is essentially an Eclipse plugin communicating to a server - via a mixture of Web Services and RPC, which in turn has the 'real' client installed. As you would expect this seems to have some performance trade-offs, and it also feels to me quite unstable at the moment, often throwing strange errors unrelated to ClearCase. It's certainly better than nothing though.

This, of course, raised immediate problems for me as I refuse to go back to using ClearCase directly now that I've tasted the good (and fast) Git life. Because I obviously can't seem to help myself I ported the gitcc to Java to use their new libraries, although it's definitely the last time.

One good thing to come out of this new version is the cross-platform ability to login as any user, bypassing the domain-specific authentication that is normally used. At least in my situation ClearCase was authenticated via our Windows domain and I could see no quick and safe way to switch between users. This was/is essential for us to preserve the identity of the author of each commit in ClearCase. I strongly suspect there is a way around this, but for the life of me I couldn't think of any. The one alternative that occured to me would have been to run gitcc on something other than Windows configured with NFS and 'sudo su' to each user as required. For reasons I am unable to articulate I wasn't all that happy with the idea and never bothered.

I've been running a gitcc daemon at work for the past week with great success. It's funny how the speed difference of pushing/pulling affects your work habits. Before I used to watch the checkin and rebase console output, like being glued to TV. Especially because we're using UCM this could take up to a few minutes to do it's rebase/deliver business, which would distract me and I would often 'hold off' on pushing or pulling because I wanted to do it all in one hit to save time. I no longer have that problem, being able to 'fetch' whenever I like, knowing it only takes (literally) a second to complete. Of course in the background the daemon is chugging away, syncing with ClearCase at its own slow-and-steady pace.

Git seems to be finally taking off at work, after a slow and bumpy start. Personally I'm thrilled to be using Git at work regardless of what anyone else is doing. However some part of me isn't satisfied with just stopping there. It pains me to see others at work using a sub-par tool when I know there is a much better one available. The worst part is that most of them don't even know what they're missing, having never used anything else. Having originally come from SVN I couldn't bear to have to checkout files every time I wanted to make a change and I knew it didn't have to be that way. A co-worker even commented that they 'like' knowing when they're modifying files just in case they accidentally typed something without realising it. That may be true, but I strongly suspect after using Git for a few days they would be unlikely to revert. That's not even taking into consideration the many other benefits of using a DVCS - like local branching.

What remains is the biggest hurdle: taking it to the 'next level'. A handful of developers are currently using it individually, but now that we have daemon available we can start to look at essentially ditching ClearCase, at least for our team. Part of the problem with working for a 'largish' company is their slow and cautious approach when introducing new technologies. From their perspective they have to consider what happens if I get run over by a bus tomorrow (those damn buses - always threatening to run us over). No one else really has the same intimate knowledge of gitcc and its inner workings. How much time and money would be wasted having to fix it, or revert to ClearCase if I was no longer there? The other issue is one of training and expertise. Now you have the problem of supporting two completely different source control systems, including training for, and maintenance of, both.

The final problem that I face is one of Git's maturity. I love Git. Without a doubt it is the most advanced version control system available today. Sure it's got more than its fair share of warts, but I wouldn't use anything else (yes I know about Mercurial, and in any other universe without Git I would be using it quite happily). Unfortunately what it lacks at the moment is all that boring Windows GUI and administration tools that managers and non-technical people need (and I don't just mean TortoiseGit). I'm sure they'll be here soon enough, but in the meantime I would still hesitate if asked 'is Git ready'. The problem is that the viable alternative, at this very second in time, would most likely be SVN, which isn't a bad system, but when compared to any modern DVCS it looks increasingly archaic. If we switched to SVN now I strongly suspect there would be pressure to switch (again) to something more powerful in the not-too-distant future.

I'd love to use Git at work as our sole version control. Unfortunately as a developer I don't really have the time or patience to play politics and ensure that all aspects of a migration are planned for. However, it seems silly to me that if a majority of your developers start to use an alternative system for any aspect of work then there isn't some reflection on your current one and how you can make your working environment that much more productive. I'm not suggesting for a second that we replace ClearCase tomorrow. Instead I am simply proposing a gradual adoption, or at least trial, of Git over ClearCase. Hell, we're pretty much doing that now anyway, just not officially.

Finally, the other revelation to come out of this is how truly entrenched in Java I have become. I found with the Python implementation I would often worry about making changes because I would have to spend part of the time investigating how to implement something 'in Python' rather than just being able to focus on the problem at hand. This has nothing to do with Python, it still remains a fantastic language, but perhaps says something about me getting older and less adaptable when learning new things. I hope I never reach that point where I'm too afraid to try something new, although I'm certainly becoming far less likely to (at least seriously) learn a new language in my spare time. I'm just hoping one of these days I get to use Haskell at work. :)
Read and Post Comments