An Homage to Mercurial

I believe without a doubt--even knowing what I know now--that I made the right decision at the time. If I could go back to 2009 and do it over again, I would still go with Mercurial. If I were starting from scratch in 2020...that's a different story.

An Homage to Mercurial

Using version control with Access isn't easy.  

In 2009, when I first decided to take the plunge, I did lots of research.  All the version control solutions available for Access used a centralized repository model. In that model, there is a central repository that holds the master copy of the application.  Developers "check out" individual forms, reports, or code modules.  While the object is checked out, it gets locked for all other developers.  No one else can edit the object until it gets checked back in.

That model was not going to work for my company.  There were only two of us and we each had our own laptop that we used for development work.  We didn't even have a device that could act as a central repository.

Luckily, the software world was in the midst of a transition away from that centralized model and towards a distributed model.  At that time, there were lots of "distributed version control systems" (DVCS) popping up.  The most popular ones were Git, Mercurial, and Bazaar.  

Git and Mercurial were already starting to pull away from the pack.  I had written some Python by then, so Mercurial appealed to me (it is written in Python).  I read lots of comparisons between the two, but my favorite was the one that likened Mercurial to James Bond and Git to MacGyver.  (It saddens me to realize that many readers may not get the MacGyver reference...he was my childhood hero.)

This paragraph from the article felt like it was written directly to me:

In contrast to git’s philosophy of providing a flexible platform built out of individual components, Mercurial is monolithic and (relatively) inflexible. Developers who like to keep their system clean will probably appreciate the fact that hg installs one binary in contrast to the 144 that make up git, and developers who think that git’s ability to edit your previous commits is moronic, unnecessary, and dangerous will appreciate the simplicity hg provides by omitting that particular feature.

There were major websites that supported both projects: Github for Git and BitBucket for Mercurial.  Both were in their infancy.  They offered roughly the same features.  No tiebreakers here.

The final nail in the coffin for me was Windows support.  Frankly, Git's support for Windows was abysmal in 2009.  There were no good GUI interfaces.  In fact, the Git community seemed openly hostile to such an idea.  They treated the command line interface like a shibboleth that protected their gated community from the unwashed masses.  "No, there's no graphical interface for git and if you need that crutch you're not worthy of git's greatness anyway."  I was more than a little tired of all the programmer condescension at this point, so that was a big turn-off for me.

In the end, I chose Mercurial.  TortoiseHg was--and is--a phenomenal front-end graphical interface.  I never did integrate with BitBucket; I backed up my repositories to our Webfaction server instead.

I believe without a doubt--even knowing what I know now--that I made the right decision at the time.  If I could go back to 2009 and do it over again, I would still go with Mercurial.  If I were starting from scratch in 2020...that's a different story.

It pains me to say it, but Git won.  There's no clearer sign of that than BitBucket dropping support for Mercurial this year. I know it's the direction my company needs to go moving forward, but I don't have to be happy about it.  

Mercurial, I implore you, Do not go gentle into that good night.  Rage, rage, against the dying of the light.

Image by Andrew Martin from Pixabay

Comments

Sign in or become a No Longer Set member to join the conversation.
Just enter your email below to get a log in link. (This will also subscribe you to my weekly newsletter.)