Control your Versions, don’t let your VCS control you

Like e-mails, blog posts should not be written while angry. Because my career isn’t on the line here, I’ll go ahead and break that rule.

It all started when I began working with two developers (Mike and Tiffany) on some projects.


The problem?

They use Git, I use Mercurial.

After doing a lot of research comparing Git and Mercurial, I decided to just go with Git.

In total, I’ve spent about 20-30 minutes of my life learning and figuring out issues with Mercurial.

In the last few weeks, I’ve spent at least 2-3 hours with Git because it has been a hassle each time I need to pull updated from the origin, or push my changes.

These were all simply annoying until the fateful evening of 9/16/2014.


The horror

I had done a few hours of work over a few nights trying to work out some bugs, and I finally went to commit because the bugs were gone. I committed, and went to bed.

(Note: Some people will argue that you should commit every hour or two, it’s a VERSION control system, I don’t believe in saving half-working code because I’m going on a lunch break)

Tonight, I launched my solution file in Visual Studio only to find out that my projects weren’t loading. “That’s strange”, I thought. Then I proceeded to look inside the project directory and gaze upon the bareness in shock. It was gone, all gone. Somehow, only a few of the publishing directories and my SLN file were left intact.


The real lesson

Now, I’m sure at this point the Git afficianados reading this are on the edge of their seats screaming “YOU PROBABLY RAN … COMMAND! IT’S YOUR FAULT!”

Ok, I’ll take the blame. I could learn more about Git. I could also spend time doing a lot of things instead of writing code like I want to. Refer to my figures before – I’ve spent about 20-30 minutes reading Mercurial documentation and have not had a single catastrophic failure like this in 2 years. I’ve spent far more time than that on Git, and in less than a month I’ve had a catastrophic failure.

The lesson? Use what works for you! Maybe I’m just not wired in a way for Git to make sense, that’s OK, because Mercurial does.

So, don’t worry about what the “cool kids” say is the best Version Control System – just make sure you’re managing your code in a way that works for you.

The moment this happened, I couldn’t help but remember one of the posts I read while researching this. Here is an excerpt from a Stack Overflow answer to the question “Is there any harmful commands  using Git and HG” :

In short:

  • Mercurial is safe by default, but adding chainsaws can completely break it.
  • Git is built out of chainsaws from the ground up, increasing apparent danger, but there are safeties.


The solution

Some of you may be wondering what I did to solve this issue. I spent a bit of time trying to figure out what I would do as well. Then it hit me. I think I’ve written a blog post about this before…

I have my Backblaze set to automatically back up my files. I just had to log into the website, go back to last night at 11 PM and download a copy of the project folder. I got my 200 MB backup of the folder in less than 20 minutes. This service just paid for itself for the next year!




  1. I’m a longtime git user, and I love it. I’ve never tried Mercurial, but I have nothing at all against it. It sounds like a capable dvcs that helps devs get work done.

    Like others, I found the learning curve with git to be pretty steep, and I had a few experiences where I felt like I’d broken everything and didn’t know how to fix it. I was glad to have a recent backup too.

    Reading your post, I wondered how much prior experience you had with other version control systems, particularly Subversion. From the little I know, I have the impression that Mercurial and Subversion share similar some paradigms and syntax. If Mercurial is your first vcs and you’ve truly only spent 20-30 minutes of your life learning it, well, kudos to you. That’s impressive.

    In my case, I certainly spent quite a lot more time learning about Subversion, and CVS before it, and RCS before that. They all share something of a lineage of paradigms and syntax, so moving from one to the other felt mostly like an expansion of concepts.

    I didn’t feel that way moving to Git, however. Git uses some of the same terms as Subversion, but often they behave very differently. Once I finally wrapped my head around Git I realized that in some ways it was harder for me to learn because I came to it from a strong background in Subversion, and that led me to make some wrong assumptions. I expect I’d have had a much easier time picking up Mercurial I wonder if that might have been the case with you too.

    Final note: You seem to be more rational and level-headed when posting while angry than most people are when posting while calm!

    1. Thanks for your comment Rick. I haven’t had the opportunity to work with other version control systems before Mercurial. To be perfectly fair, the learning curve was probably shortened because most of my Mercurial work is done in TortoiseHg (Mercurial GUI). I prefer to use this to check in my code because I find it easier to confirm my changes as opposed to many lines of code scrolling by as changes. There is also TortoiseGit but it is not nearly as complete as the Mercurial version.

      1. Ah, yes. The Tortoises can be very helpful. I haven’t used one in quite a while, but I recently learned that TortoiseGit represents concepts a little differently than Git itself does, which I found a little confusing!

  2. I’m rather curious to hear what actually happened to cause this, if you ever worked that out. I’m a “has read the manual from cover to cover” style Git user, but I work with a lot of people who quite reasonably don’t want to invest that kind of effort in a tool that just doesn’t excite them. It would be really valuable to hear what kind of operation leads to such a horrifying failure mode.

    1. I don’t know the exact commands that I was trying, but I had some files that were added to the repository a few versions ago that I wanted to stop tracking. These were graphical files that were really ballooning the size of the repository. I also wanted to remove them from the history to save space. I believe I tried a few commands I cobbled together from Stack Overflow posts and Google hits. As you can tell from the original post, it didn’t go to well.

Leave a Reply

Your email address will not be published. Required fields are marked *