Version Control

For a long time I’ve used Bazaar as my version control system. I’m sure that people have lots of opinions on this, but let me present why I chose this:

  • I wanted to be able to put empty folders in the repo.
  • I particularly liked the automatic rename detection in Bazaar. It does better than most other VC systems in that regard.
  • It was simple to use.
  • It’s fast.

There were probably other reasons, but those are the main ones in terms of practical reasons.
However, the main reason I chose it was I didn’t want to choose the other options.

The other options I considered were, of course, Git and Mercurial.
I didn’t want to choose one because I didn’t want to be seen as taking a side. Amongst a number of people you’ll find some interesting arguments over which one is better. I always find “my tool is better” arguments to be rather silly, so I opted out of them by opting for a different tool entirely.

Let’s discuss them a bit, before I get to my main point.

I’ve read a post about how Git is MacGyver and Mercurial is James Bond. I found the analogy quite apt (especially since they are both prone to making things go boom, so it’s fair).
Particularly, Git is complex; everything has it’s own tool or command and it’s a ridiculous Swiss army knife of gizmos which you pretty much have to be an expert to work with consistently. However, if you CAN work with it well then it’s really powerful.
Mercurial, on the other hand, takes a more monolithic approach; it’s got some nice gadgets for when you really need the laser watch, but it doesn’t expect you to use the laser watch on a daily basis. Instead, it gives you the core set of tools which will generally keep things running smoothly. It’s slick, fast, and likes its drinks simple.

This is as it should be, really. This is how they were designed.
Git was designed by an expert for experts. The expert in question didn’t think much of non-experts, so he didn’t care that it was complex.
Mercurial was designed to be fast and smooth. Nailed it. Mostly, anyway.

Bazaar… is just kind of there. I’m not sure what their main motivation was for creating it, but maybe Canonical just wanted their own version control system. Microsoft made one too, so it’s not unprecedented, but at least Bazaar works.

At any rate, back when I was choosing a version control system to graduate to (from SVN… *shudders*), I did my research… and while I found the above analogy good, I was completely disillusioned with either Git or Mercurial due to all the online arguments. I chose Bazaar.
By most comparisons, the three are nearly identical for basic use. They diff, they branch, they are distributed, and they are pretty much the same speed for most operations.

Now, years later, I’ve used both Bazaar and Git first hand. I have some new opinions on the matter.

This past week I was in Italy for a code camp with my colleagues (from various countries), and it turned out I was the Git expert. I found this funny, because I know Git from working on Forge.
However, I was also pushed into the role of fixing the repos and getting everyone working happily on their branches. This included some interesting and serious stuff that I hadn’t had a lot of practice with. I knew how to do it, roughly, but I’d not done it everyday for a week before.
I’m now pretty confident that I AM a Git expert…

And I like Git, suddenly.

Previously, when working on Forge changes, I’d always find Git slightly painful. It worked, but, in terms of version control systems, it’s the most likely to break. Or do something weird. Or eat stuff. Or produce nasal daemons (look that one up; you won’t be disappointed).

So, now I’m considering moving my personal repos from Bazaar to Git. The biggest thing is I’ve taken to certain features such as the branching mechanics of Git (especially the visualization and rebasing). The visualization features actually make it really rewarding (to me) to make branches. I know, I’m weird, but what can one do?

However, one of my original gripes with Git still exists: You cannot put an empty folder into the repo. This is because Git has no concept of file hierarchy; the names of the files include the hierarchy implicitly. This means renaming a folder actually is renaming all of its contained files individually. There are tricks to force a folder into the repo, but it requires creating dummy files, which is against my rules for repos, and it still doesn’t solve the renaming.
Git’s concept of a file is also a bit different, as Git considers changes, not snapshots or files or folders. This is where the limitation comes from. I admit that the tradeoff is pretty worth it for the underlying mechanics, though.

Some of my projects are going to need to migrate anyway, so I’ll do those and see how that goes. Bazaar includes systems for conversion to and from other version control systems, so that’ll make it easy. Now that I think about it, that option was one of my original reasons for selecting it.

Long post for something most people won’t care to read about, but I hope you enjoyed it. Let me know what you think! πŸ™‚

4 thoughts on “Version Control”

  1. I didn’t know about Bazaar, so I took a look at the docs, and honestly I found it pretty similar to Git, the ‘add’ and ‘commit’ commands have the same syntax (at least in their simplest usage).
    I chose to use Git because it was the most popular VCS, and thanks to the integration in many apps like IDEA or Atom I rarely have to use Git from the terminal. To put an empty folder in a repository, I usually create an empty .gitkeep file. I think it’s more a matter of habit, as I never found Git that hard to use.

  2. I realise this is somewhat late, but I thought I’d add a note.

    I also migrated from Bazaar to Git (indeed at one point I worked for Canonical around the time Bazaar-NG was being produced). The lack of empty directories used to be a problem for me but I eventually got around it by injudicious use of Makefiles πŸ™‚

    Internally, Git actually only considers whole trees of content. Changes are synthesised as a storage optimisation rather than in bazaar where the changes themselves were more relevant.

    As such, things like rename detection is entirely heuristic in Git which has benefits as well as issues.

    Enjoy your transition to Git — these days I find bazaar feels annoyingly Grandpa-ish :-/

    D.

  3. So I’m looking for your blog post on modpacks, and came across this.

    > Git’s concept of a file is also a bit different, as Git considers changes, not snapshots or files or folders.

    At this point, I know enough to know that’s not accurate. Git does store every file, every version, as an intact full file.

    Now, I agree that file *names* are an issue — git considers two sufficiently similar files in different snapshots to be the same, even if they have different names. It wants to track file renames, and frankly, I think this is better than the alternative more often than not.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.