Plugins in Version Control

What is up with these version control systems that use plugins to do everything? I understand that having an extensible system is very useful if users want to create something custom. Mercurial and Bazaar both support plugins written in Python, while Git has an extensive set of commands that allow you to easily write custom scripts in any language.

However, being able to extend a program is not an excuse to ship a product missing features. One of the things that makes Git powerful is that it ships with a lot of capabilities built in.

Take Bazaar for example. If you want to commit only part of the changes in a file, you need the BzrTools extension. To rebase revisions you need the Rebase extension. You need extensions to show diffs in colour, to push all branches at once, and even to remove untracked files in your working tree! Why aren’t these included by default? Are they afraid a user might be afraid to see a coloured diff? Or is it too much work to support these tools directly?

This exactly the problem with plugins: it separates the functionality from the main program. Who is going to install some weird plugin on some website to gain functionality? Who created the plugin anyway, can it be trusted as much as the program itself? How is it updated? What if there’s an incompatibility between the plugin version and the program version? What if I’m using some feature, but others that I’m working with can’t do the same, because they don’t have the plugin installed yet?

Having an extensive set of tools shipped by the program isn’t a bad thing, it’s good. It allows you to use the same workflow and suggest the same solutions to everybody else, without requiring a certain plugin. It also makes features easier to use, as you don’t have to manually install something first.

Git is easily capable of supporting its full feature set release after release, and keeps adding useful features. When upgrading, you can be sure that all your previous commands are still usable. As they are integrated into the system, you can be sure that they get the same amount of attention as anything else.

This last point is more important than you might think. After all, you’re talking about your source code here. You want the program that you use to be reliable, to work consistently across releases. You don’t want to depend on something that you don’t fully trust.

Relying on plugins is just a way for lazy programmers to maintain less code. I really prefer Git’s builtin tools more than some lousy plugin that doesn’t even have it’s own website. If you stick to only core functionality, at least be the fastest ;).

Git Repack Parameters

A few people have asked my if I chose the parameters for Git’s repack correctly. Shouldn’t I use a higher --depth value than the default? Why did I pick a --window value of 250? Shouldn’t I have repacked with the default values?

To answer this first question last: no. I did these conversions as best as I could, in order to make a fair comparison. My assumption is that anyone converting their repository to Bazaar, Git or Mercurial knows what he or she is doing. Then why should I settle for less? Repacking a repository as tightly as I did is necessary only once, but it is an important step: git fast-import creates really bad packs in order to be fast, so a repack really helps. It is also suggested in the manpage to use a higher —window value than normal.

However, it got me curious on how the parameters (--depth and --window) influence final repository size. First I wanted to see if changing the --depth would have made a difference in final size. I repacked all repositories, with a depth value of either 50 (the default) or 100. I varied the window parameter over the values [10, 20, 50, 100, 150, 200, 250].

First let’s look at how the depth variable influences repository size.

As can be seen from this figure, increase of repack depth only influences repository size on a repack with a small window. As I used a window size of 250, the depth variable did not influence results much.

However, it’s also interesting to see how these variables affect other parameters. An example of this is repack time.

Repack time still increases with increasing window size. As a repository won’t be packed much tighter on a window of 250 than on a window of 100, you might as well choose a lower value for your window when doing an aggressive repack.

However, there is a more interesting interaction going on: the effect of the window parameter depends on the size of your repository. Let’s look at repositories of different sizes (See “Meet the Candidates” for a description of the repositories):

As can be seen, a higher window value will have an effect only on repositories that are actually quite large, like the emacs repository. If you have a small repository, there’s not much use to repacking with anything higher than --window=50, but if your repository is several hundreds MB’s, it skim off a few more megs.

(Please note that the repack times are done on an Intel iMac Core Duo, 2Ghz with 2GB RAM running OS X. Repacks are done with git repack -adf, which means that a repository will be completely packed. If you do a normal, incremental repack, expect to see much faster repacks.)

On mainline merges and fast forwards

Bazaar has a somewhat different notion of merging in the case of no new commits than Git and Mercurial do. The reason for this is the notion of a “mainline” in Bazaar. This supposed mainline is meant as a silver line through your history. All commits should be merged into this mainline, giving you a nice overview of development. Bazaar has even integrated this into their “log” tool: commits that have been merged “into the mainline” are indented to show this.

Git and Mercurial use another approach, based on the fast-forward method: If there are no new commits on your branch, but there are new ones on the remote, Git and Mercurial just fast-forward you to that commit. No merging or so, your new HEAD will just be the same revision as the remote.

The reason they do this is because Bazaar’s approach does come with some problems. The first and most obvious of this is performance. The “bzr log” command is really slow as it reconstructs history every time, figuring out what the mainline actually is and then showing the history in a neat way. This scales badly: For Cairo, with 4000 commits, “bzr log -l10” takes just over a second to display the first 10 log messages. Mozilla-central, with 15000 commits, already takes 5 seconds. Samba with 24000 commits takes 10 seconds to display the first few log messages, which I would call unacceptable. It gets even worse when you try the Emacs repository.

However, that is not the biggest problem. The problem with explicit merges is the pollution of your branches. The outlining Bazaar makes is only useful if it is “correct” and does not show pollution. This can be a real trouble when two developers work together on a single feature, and merge with each other.

An example

Let’s say that we have a single upstream with some commits. There are two people working on something, one in the branch1 branch and the other in the branch2 branch. Both do a commit on their own branch, then branch1 decides to merge with branch2. After this, branch2 merges with branch1, to get their features.

What this means is that after both have merged, they should have the same tree (given that the merge was conflict-free). One might therefore also assume that they have the same branch history. This is not true however.

Show branch1 log

Show branch2 log

Who is right here? Should the “Add b” commit be indented or the “Add c” commit? As you can see, the notion of “mainline” is then local to a developer, beating the whole point of having a “global line through history”.

It gets even worse. Suppose branch1 merges the changes from branch2 again (just to make sure he has everything) and pushes it to upstream. Then branch2 updates from upstream in order to continue working. The final output of his log looks like this:

--------------------------------------------
revno: 4
committer: Pieter de Bie <pdebie@ai.rug.nl>
branch nick: branch2
timestamp: Tue 2008-06-03 16:25:55 +0200
message:
  Merge with upstream
    --------------------------------------------
    revno: 1.1.3
    committer: Pieter de Bie <pdebie@ai.rug.nl>
    branch nick: branch1
    timestamp: Tue 2008-06-03 16:25:52 +0200
    message:
      Merge with branch2
--------------------------------------------
revno: 3
committer: Pieter de Bie <pdebie@ai.rug.nl>
branch nick: branch2
timestamp: Tue 2008-06-03 16:25:51 +0200
message:
  Merge with branch1
    --------------------------------------------
    revno: 1.1.2
    committer: Pieter de Bie <pdebie@ai.rug.nl>
    branch nick: branch1
    timestamp: Tue 2008-06-03 16:25:49 +0200
    message:
      Merge with branch2
    --------------------------------------------
    revno: 1.1.1
    committer: Pieter de Bie <pdebie@ai.rug.nl>
    branch nick: branch1
    timestamp: Tue 2008-06-03 16:25:45 +0200
    message:
      Add b
--------------------------------------------
revno: 2
committer: Pieter de Bie <pdebie@ai.rug.nl>
branch nick: branch2
timestamp: Tue 2008-06-03 16:25:47 +0200
message:
  Add c
--------------------------------------------
revno: 1
committer: Pieter de Bie <pdebie@ai.rug.nl>
branch nick: upstream
timestamp: Tue 2008-06-03 16:25:42 +0200
message:
  Base commit

Does that look readable to you? This does not show a nice overview of what has happened during the development of a feature. Instead, it is littered with merges. This kind of noise may make developers wary of merging, which is not good.

Compare this to how Git and Mercurial handle this. Even after the to- and fro merging, the log still shows only four commits:

commit 78cd0c44cd93800a169617a72832bcb6a984f9a3
Merge: 598b3f8... ecc0685...
Author: Pieter de Bie <pdebie@ai.rug.nl>
Date:   Tue Jun 3 17:04:27 2008 +0200

    Merge comparison/temp-dir-2/branch2

    * comparison/temp-dir-2/branch2:
      Add c

commit 598b3f859ff9f69733a2ddd1406229cd3c203591
Author: Pieter de Bie <pdebie@ai.rug.nl>
Date:   Tue Jun 3 17:04:26 2008 +0200

    Add b

commit ecc06852b9f76cdcf9285f6eac7c39c002e566e7
Author: Pieter de Bie <pdebie@ai.rug.nl>
Date:   Tue Jun 3 17:04:26 2008 +0200

    Add c

commit 5828b28ff1fc41c674cabe9b839621a72f3effa5
Author: Pieter de Bie <pdebie@ai.rug.nl>
Date:   Tue Jun 3 17:04:26 2008 +0200

    Base commit

Implications

The important point of this is that in the way Git and Mercurial work, it doesn’t matter who does the merge. Their workflow encourages the use of forking, giving more freedom to the developers to do what they want and merge with whom they want. The Bazaar approach, in contrast, discourages merging by anyone else than those in control of the mainline, as otherwise the history will look ugly and unreadable: the first branch is somehow “special” and must be maintained that way. In a distributed VCS, it should not matter who does the merge. By making sure that the maintainers have to merge from you, you get less freedom in deciding how to do your development.

While the outline may seem nice, sometimes having it is just plainly wrong. If I want to update my branch to the latest upstream, I want to be equal to the latest upstream, not to make it a merge. Also as we just saw with cross-developer merging, there sometimes is no way to determine who is “the mainline”. Making a simple branch something that it isn’t is only bound to spread confusion among the users.

See also this reply by Linus Torvalds that basically says the same thing. Also take a look at the rest of that thread if you’re interested.

Git, Mercurial, Bazaar Repository Size Benchmark

I have finished all conversions of the repositories that I’m going to test. The first interesting metric is of course the repository size. This is interesting because Bazaar claims on its homepage that “Bazaar’s default storage format is highly efficient, better than its main competitors in most cases”. They include benchmarks which should show that they are more efficient than specifically Git and Mercurial.

As I mentioned before, this benchmark is bogus because it does not include project history. While Bazaar acknowledges this, they still mention space efficiency as one of their prime benefits. They also mention that their benchmarks are done on real use cases, not arbitrary processes.

At the same time, Mercurial states it has an “Extremely high-performance delta-compressed storage scheme”. Git mentions “It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.”

Test method

For all repositories, only a single branch was converted. For all repositories except Samba, this meant the development branch. As Samba has multiple development branches, I chose the v3-3-test branch.

I made use of the fast-export/import interface where possible. This means that all conversion were done using fast-export, except Git to Mercurial, for which I used “hg convert”, and Bazaar to Mercurial. This last one was a bit tricky, as Mercurial has no Bazaar importer. I therefore converted the Git repository of the same repo to Mercurial.

After conversion, I ran a pack command for the repositories that support this. For Git, this meant a “git repack -adf —window=250”, for Bazaar it meant a “bzr pack”, and removing the obsolete packs.

Tests were done using Git v1.5.5.3, Bzr v1.5, Hg v1.0

Results

So then, using actual, real world data, which system has the best storage efficiency? Below is the table of all projects.

Repository	Git	Mercurial	Bazaar
Git
Cairo	15MB	24MB	30MB
Coreutils	29MB	44MB	76MB
Samba	82MB	146MB	310MB
Mercurial
Octave	22MB	49MB	57MB
Mozilla	78MB	205MB	255MB
Dovecot	9MB	14MB	23MB
Bazaar
Emacs	120MB	163MB	300MB
Mailman	42MB	75MB	73MB
Pkgconfig	1.1MB	1.3MB	1.8MB
Total	398MB	721MB	1125MB
Relative	1	1.8	2.8

Finally

As can be seen from the table, Git really is the most efficient in storing the data. Next up is Mercurial, which also does a nice job. Bazaar is the least efficient by far, taking on average 2.8 times the space of an equivalent Git repository.