The Changelog - Programming

Knuth and Reusable Code

nospam@example.com (John Goerzen) — Wed, 30 Apr 2008 17:48:17 -0500

In the recent interview with InformIT, Donald Knuth said:

I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.

I have tried in vain to locate any place where he talks about this topic at greater length. Does anyone have a link?

At long last, software.complete.org migrated to Redmine

nospam@example.com (John Goerzen) — Sat, 15 Mar 2008 15:50:31 -0500

I've been writing a bit about Trac and Redmine lately. For approximately the 1/3 of the publically-available software that I've written, I maintain a Trac site for it at software.complete.org. This 1/3 is generally the third that has the most interest from others, and there's a bug tracker, wiki, download area, etc.

Trac is nice, and much nicer than one of the *Forge systems for a setup of this scale. But it has long bugged me that Trac has no integration between projects. To see what open bugs are out there on my software, I have to check -- yes -- 17 individual bug trackers.

To keep track on the wikis to make sure that nobody is adding spam, I have to subscribe to 17 different RSS feeds.

It took me some time just to hack up a way so I didn't have to have 17 different accounts to log in to...

So, mainly, my use case for Trac isn't what it was intended for.

Enter Redmine. It's similar in concept to Trac -- a lightweight project management system. But unlike Trac, Redmine allows you to have separate projects, but still manage them all as one if you please.

Redmine didn't have Git support in its latest release, but there was a patch in Redmine's BTS for it. I discussed why it wasn't being applied with Redmine's author, and then went in and fixed it up myself. (I used Git to make a branch off the Redmine SVN repo -- very slick.) Unlike Trac's Git support, Redmine's is *fast*. I tested it against a clone of the Linux kernel repo on my local machine.

There are a few things about Redmine I don't like, but I have learned that they mainly have to do with Ruby on Rails. As someone pointed out on Planet Debian lately (sorry, can't find the link), the very nature of Rails makes it almost impossible for OS developers like Debian to include Rails apps in the distribution.

Not only that, but it seems like Rails assumes that even if you are just going to *use* an app, you know how to *write* one. For instance, this is pretty much the extent of documentation on how to set up a Rails app to be able to send out mail:



  # See Rails::Configuration for more options

And of course, googling that turns up nothing useful.

Redmine is a rails app, so it cannot escape some of this. It seems to be a solid piece of work, but Rails seems to make things unnecessarily complex. That, and I've found some bugs in the underlying Rails infrastructure (like activerecord not quoting the schema name when talking to PostgreSQL) that make me nervous about the stack.

But the site is up and running well now, so I'm happy, and am planning to keep working with Redmine for quite some time.

If Version Control Systems were Airlines

nospam@example.com (John Goerzen) — Thu, 06 Mar 2008 07:44:06 -0600

Many of you have seen the net classic If Operating Systems Were Airlines. Today, let's consider what the world might be like if version control systems were airlines...

Before anyone gets mad, this is all in fun, OK?

RCS Airlines: One of the first airlines, from way back when this whole aviation thing was new and exciting. Each RCS flight carries exactly one passenger, which RCS believes is a superior way to fly. Although most RCS airplanes are rusty and battered today, RCS Airlines still retains its historic dedication to security. Each airplane is kept locked as much as possible for safety. Occasionally flights will be delayed for hours because the pilot can't open the locked plane. When this happens, the pilot will frantically try to get the cell phone number of whoever it is that has locked the plane. When the plane finally gets unlocked, you may be tempted to ask why it was locked for so long. Veteran RCS users have learned that the answer is usually disgusting, and never ask anymore. Main competitor: CP/M airlines.

CVS Airlines: Founded on the belief that they could be more efficient than RCS by carrying multiple passengers per flight. They still carry each passenger in a separate RCS-built airplane, but the airplanes fly in a goose-like ",V" formation. Watch out for layovers, though. It can take hours to merge new passengers into the formation properly, and it might take several attempts to take off afterwards.

CVS flights often feature fights over who gets to fly. CVS piloting fights are legendary; rumor has it that OpenBSD got started after CVS airlines refused to allow a passenger to board on the grounds that he had in the past refused to stow his tray table in the upright and locked position.

CVS airlines mostly counts as customers the "over-50" crowd who grew up using CVS and don't like change. Its in-flight magazine features advertisements for balding-reversal treatments and uuencode tools.

Main competitor: AIX airlines.

Subversion Airlines: Started by some grey-haired CVS executives with long, wispy beards, Subversion airlines got started by trying to be "CVS, but better". Subversion airlines was the first major airline to use planes that seat more than one passenger. Unlike CVS airlines, all passengers on a Subversion flight travel in the same plane.

Subversion airlines is famous for its Soviet-like centralized control. All operations must be approved by the Kremlin, and you are allowed, by the grace of the Party Leader, to gaze at the massive airplanes. Those that have served the Party and Airline well for many years are allowed to enter the Great Shrine of the First-Class Comitter, and actually make changes to the airplanes themselves. Plainclothes Subversion Airlines security agents lurk on every flight, and you should not be surprised to be thrown out an airplane window if you make a joke in bad taste about the pilot's flying skills.

Subversion airlines thrives on the concept that "photocopying is cheap". You are encouraged to make photocopies of your ticket, or to photocopy your photo ID, and give copies of each to as many people as you can. At checkin time at the gate, if more than one person arrives with a copy of the same ticket, they are ushered into the "merging room" and each person is given a brick. The door is closed, something magical occurs, and the one person that emerges still able to walk is allowed to board the plane.

Main competitor: Windows airlines with no Administrators allowed.

tla airlines: Founded by one of those eccentric British noblemen, Lord Tom's airline is the utopian philosopher's airline. Chafed by the heavy-handed control of Subversion Airlines, tla airlines wants every passenger to be created equal. As you approach the gate area in the terminal, you will find many philosophers occupying the gate area, extolling the virtues of tla airlines. They compare tla airlines to reaching out and touching the heavens, leaving behind the bonds of a ground-based life, actually merging with the stars. Oh, the gorgeous beauty of it all! The things we will see!

As you see people arriving from another flight, you observe that some of them have burn marks. One of them comments that "merging with the stars doesn't work." Immediately, a dozen philosophers get in a fight with him, claiming that he simply doesn't understand what it means to merge with the stars, and that if he gets his inner being in the proper state first, he'll have a much better experience.

As you board the tla airplane, you obvserve that the jetway is a mile long. The airplane itself reminds you of something of a cross between a gothic cathedral and a level of Doom. There are spectacular archways everywhere, sometimes where they don't really belong. Each archway is supported by ornate curly braces which you don't normally see on airplanes, and frankly, you'd rather not, because they look all pointy and confuse the kids.

As you arrive as your destination terminal, you see it too is full of philosophers, most of them dining.

Main competitor: VMS airlines.

Darcs Airlines: Unlike every other airline, this one uses physicists instead of engineers to design its airplanes. One brilliant Darcs physicist has finally come up with The Theory of Everything, and as such, Darcs knows where you want to go before even you do. Darcs airlines prides itself on customer service, and asks your preference for even the tiniest details about your trip.

Each seat pocket features a copy of the Theory of Everything for your reading enjoyment, but nobody actually understands it.

Occasionally, you will find that Darcs pilots get into angry conflicts with the control tower in mid-flight. This results in the control tower revoking your permission to land. Legend has it that one Darcs pilot of a plane with exceptionally large fuel tanks actually resolved his conflict with the tower and landed two weeks after taking off. Experienced Darcs users board with several parachutes: one for themselves, and a few more for the newbies.

The Darcs physicists claim that the Theory of Everything predicted the pilots would act this way, and that all pilots eventually act this way throughout the entire universe. They toil day and night finding a way to adjust the gravitational constant of the universe, thereby reducing the anger factor of the pilots.

Main competitor: OS/2 airlines.

bzr airlines: Founded by a South African who had been injured by a curly brace on tla airlines, bzr airlines aims to be "tla done right". They have shortened the jetway, gotten rid of the curly braces, chased out the philosophers, and no longer have a vision of merging with the stars. Many that were injured on tla airlines fly bzr airlines, and out of respect for tla airlines, bzr airlines will still honor tla tickets.

bzr passengers consider themselves part of an exclusive club because each flight takes off from a launchpad. They often can be seen standing in the terminal passing out bzr literature, trying to get passengers of other airlines to fly bzr, and can't understand how other airlines continue to exist while people keep walking past their airplanes.

Main competitor: BeOS Airlines.

Bitkeeper Airlines: One of the world's faster airlines, Bitkeeper airlines occupied that obscure gate for rich people at the end of the terminal for many years. Tickets on Bitkeeper Airlines were rumored to cost thousands of dollars, and were rare and jealously guarded. Then for awhile, Bitkeeper Airlines started giving away tickets for free, though they also kept around the expensive tickets for those with discriminating tastes. Free tickets were made widely available, but the 3-point type on the back of tickets said that you were never allowed to think about another airline before, after, or during your flight, and some people claimed they actually saw the small print morphing right before their eyes.

Bitkeeper flights often featured arguments over whether people were harboring secret thoughts of other airlines. If you were caught thinking about another airline, you were expected to scream vigorously while being thrown out the escape hatch without a parachute. All of this commotion tarnished the rarified air that the rich people paid to experience, so one day it was decided that there would be a Great Purge, because obviously all free ticket holders had harbored lustful thoughts of other airlines, so they were all thrown off the airplanes simultaneously. Today, people aren't exactly sure where the Bitkeeper gate is, but everyone suspects it still lurks somewhere.

Main competitor: SCO Airlines.

Mercurial Airlines: The "there's one right way to do it" airline, Mercurial is a sterile, agile, and shiny airline. Every Mercurial airplane looks identical to every other one, shiny and clean. You could swear that all the passengers look alike too, and as you approach the gate, it seems like you too look like everyone else. Mercurial passengers tend to be a happy bunch, who can't comprehend anybody that flies Git Airlines. Specks of dirt and dust confuse the pilots, so it is best to make sure you have showered before boarding. It is rumored that, through bolting on more engines, some Mercurial airlines can fly to as many places as Git airlines can, but most Mercurial passengers are content to not worry about that.

Main competitor: Python Airlines.

Git Airlines: The "there's more than one way to do it" airline, Git flies the world's largest and fastest airplanes. Git Airlines was founded by some priests who were flying for free on Bitkeeper Airlines and survived the fall after the Great Purge. Git airplanes start as spartan, empty cabins, with no carpeting, chairs, or piloting controls. At the departure gate, each passenger is handed a bag containing 173 standard airplane components, accompanied by a 4x5" sheet of information on the theory of flight, written in 1950. Once onboard, the passengers use these components to finish out the airplane for flight: installing chairs, rudder controls, etc. Every flight results in a plane assembled in a different way, and passengers on each flight believe they are flying the world's best airplane. Arguments in the terminal after a flight are common, as passengers from different flights debate the merits of their particular design.

Despite all this, Git planes turn out to be safe, and Git passengers believe they get to their destinations in half the time it takes any other passengers, though sometimes they secretly wonder if the Mercurial flight got there faster. Occasionally, passengers on Git airlines build an airplane that appears to go into a tailspin. When that happens, they simply assemble a tool that lets them go back in time and change history so that it doesn't crash, although it is rumored that if you are a member of the public watching this happen from the ground, it will lead to seizures.

Git airlines takes special pride in the one piece that passengers don't have to assemble: the plumbing. Every Git lavatory is equipped with state-of-the-art never-fail plumbing, and the best porcelain washroom fixtures money can buy. None of these cheap plastic toilets like you get on every other airline. Here, we have fine porcelain fixtures.

During a flight, after passengers use the lavatory, they frequently get into arguments with each other about which style of porcelain toilet is the best. These arguments are only resolved by the Zen-like Git Priests, who insist that only inferior passengers need to use a toilet while in the air.

Main competition: Perl Airlines.

Git Feature Branches

nospam@example.com (John Goerzen) — Tue, 04 Mar 2008 21:57:20 -0600

I'm really liking this.

So I set up some Git feature branches to help get Redmine patches from their BTS into their SVN trunk faster. (I don't know why, but it seems to take a *very* long time for that to happen.)

Each BTS patch gets a Git feature branch. My Git repo for this project has about 21 branches in it.

So, I pull upstream into a branch called, well, upstream.

Each feature branch is created off upstream.

Then, the master branch merges all the feature branches in. I wrote a simple git-merge-fb shell script that just runs git-merge for each feature branch. Very simple. I expect to have a git-pull-fb script of some sort that merges upstream into each feature branch when I update against upstream. It could also run a diff at the end to see if there is any difference remaining, and if not, delete the branch.

It's trivial to give an updated diff to upstream for any given patch: git diff feature-blah..upstream will do it.

I only wish gitweb had a way to do that so I could just hand out a URL that always corresponds to the latest diff against upstream for a given feature. Now that would rock.

Thoughts on Redmine

nospam@example.com (John Goerzen) — Mon, 03 Mar 2008 05:05:00 -0600

A few days ago, I discussed Trac and Redmine. Redmine is a project management tool, similar to Trac, with built-in download tools, bug tracking, etc.

Redmine has a lot of nice features. Chief among them is better integration between multiple projects, so I don't have to go to 17 separate pages to see the open bugs on my projects.

But I'm worried about the Redmine community. It appears to live in an insular Ruby world, without much participation outside. I wrote about some of those concerns in their forums. I've also submitted bugs to Redmine, some with patches.

Also, it's concerning that, although Redmine includes a very nice forum module, the Redmine forums are still on RubyForge. Also, there are many bugs in the Redmine BTS that have patches but little, if any, comments from the Redmine people that have commit access.

It could just be that Redmine is a fairly new project and just needs some time to get on its feet more. It's been around since July, 2006, which isn't all that long on the one hand... or quite awhile, depending on how you look at it.

The git support patch for Redmine looks very nice. However, after a month, it still hasn't been replied and there's no indication why. Which also is troubling.

So I think I'll sit with Trac for a little while until I get a better feel of how Redmine is progressing.

hg.complete.org is no more

nospam@example.com (John Goerzen) — Fri, 29 Feb 2008 06:41:00 -0600

As of today, hg.complete.org is no more. I have removed mercurial and hgwebdir from my server, removed hg from my DNS zone, and converted everything that was in Mercurial over to Git. (Except for hg-buildpackage, which I have orphaned) So there is now stuff at git.complete.org.

I still have a ton of Darcs repos to convert, which will take more time.

Also I have heard a lot of people say that the GitPlugin for Trac is not very good. I have two Trac instances running it: one for commithooks and another for ListLike. Both seem OK so far, but I haven't pushed them very much yet.

Trac & Git

nospam@example.com (John Goerzen) — Thu, 28 Feb 2008 21:29:40 -0600

For quite some time now, I've been running Trac over at software.complete.org. Most of my free software projects -- well, the ones where I actually go to the effort to make formal releases -- have a Trac instance. This Trac instance provides a wiki, bug tracker, downloads area, timeline (with RSS feeds), and VCS integration.

Trac is a nice program, but one thing has bugged me about it all this time:

Every trac instance is its own island.

I have 17 trac instances out there for my projects. To see what bugs are out there on my own server, I have to check 17 websites (or 17 RSS feeds or whatnot). Publishing a new program is not a lightweight process.

So today I started poking around looking for something better. I really like Trac's way of integrating the wiki with the BTS and the commits; wiki markup can refer to a bug or a changeset, and bugs can use wiki markup too.

I looked at Redmine, Mantis, and Roundup, and I also have experience with RT.

Of these, Redmine looks the most interesting. Multiple projects support, per project wiki and forums, gantt charting even, and support for SVN, CVS, Mercurial, Bazaar, and Darcs -- with Git support out there as patches to their development tree already too. Oh, and I saw references to a Trac importer as well. One thing that makes me nervous, though, is that they have no links to sites that use Redmine (except one in the news section), and Google isn't turning up users either. Does nobody use this thing?

What else should I be looking at?

Over on the Git side, I'm still liking Git. I have now migrated several Mercurial projects over to git (see git.complete.org). I am also playing with Darcs to git migration using darcs2git, which also is going well. Sometimes gitk shows a nicer representation of a Git repo converted from Darcs than I was able to get from Darcs.

Experimenting with Git

nospam@example.com (John Goerzen) — Tue, 26 Feb 2008 17:24:00 -0600

I've been writing about Git a bit lately.

I've decided to switch some of my Debian work over to it to start with, as well as some of my other projects.

Although I was thoroughly frustrated with Git a year ago, now I am quite pleased with it. What's different? The documentation is a LOT better. So far I have only found one manpage (git-show) that omits lots of its options. The system is friendlier, keystroke-happier, and powerful.

Compared to Mercurial, I've found some nice things:

In-directory branching. I didn't expect to care about this, since both git and hg permit lightweight clones. But it turns out to be so easy to use that it is great. Especially since I don't have to setup multiple branch repos on the server. I really like this. Note that "hg branch" is not the same as a git branch, and see the discussion on the hg lists about renaming that before 1.0.0 for why.

Flexibility in getting things around. Plain HTTP works fine (no static-http:// hack). ssh. git daemon. rsync. Very slick.

Performance. Surprisingly, git actually feels faster than Mercurial, especially when pushing or pulling. I didn't expect that.

Tags. They seem smarter in git. No more merging of .hgtags all the time. Also I like that I can attach a message to a tag and sign it.

All that power. There is a *lot* that Git can do. I should have been taking notes about it all.

My main complaint is still that Git doesn't have something as nice as "darcs send". Mercurial doesn't either, but it's a bit closer. Git has moved closer, but still has room to improve on that.

So I have set up git.complete.org and am starting to publish my Debian stuff on Debian's alioth server as well.

Also, hg-fast-export in the fast-export project is *awesome*. Branch-aware and everything. It made a perfect Git version of my Mercurial work.

Git looks really nice, until....

nospam@example.com (John Goerzen) — Sun, 24 Feb 2008 18:57:08 -0600

So I have been learning about Git this weekend. It has some really nice-looking features for sure -- some things Mercurial doesn't have.

I was getting interested in switching, until I found what I consider a big problem.

Many projects that use git require you to submit things using git-format-patch instead of pushing/pulling from you. They don't want your merge history.

git-format-patch, though, doesn't preserve SHA1s, nor does it preserve merges.

Now, say we started from a common base where line 10 of file X said "hi", I locally changed it to "foo", upstream changed it to "bar", and at merge time I decide that we were both wrong and change it to "baz". I don't want to lose the fact that I once had it at "foo", in case it turns out later that really was the right decision.

When we track upstream changes, and submit with git format-patch, the canonical way to merge upstream appears to be:

git fetch; get rebase origin/master

Now, problem with that is it loses your original pre-conflict code on a case like this.

There appears to be no clean way around that whatsoever. I tried a separate "submission" branch, that rebases a local development-with-merge branch, but it requires a ton of git rebase --skip during the rebase process.

Thoughts?

Two new bashisms

nospam@example.com (John Goerzen) — Fri, 22 Feb 2008 18:22:04 -0600

I learned about two bash features I hadn't known about today.

From a colleague, GLOBIGNORE. A colon-separated glob of files to ignore when expanding globs. Helpful behavior when set to "*~" and used with grep.

From the Git FAQ, in a section explaining that it breaks the Git build process, CDPATH. A colon-separated search path to use when you type cd. Possibly useful to refer to subdirs of ~ or other common areas. Seems like it's prone to break a ton of scripts if exported though.

Haskell Fun

nospam@example.com (John Goerzen) — Fri, 03 Aug 2007 03:52:04 -0500

Bryan O'Sullivan noted over at the Real World Haskell blog that Haskell made quite the impact at OSCon. And I can attest to Simon Peyton-Jones having trouble leaving the building because of all the people that wanted to talk to him about Haskell. It was interesting to think about "why now" for Haskell's popularity. Bryan's post has links to the video of Simon's talks, which are great. (Sample quote: "Oh look, a whiteboard has appeared as if by magic! What joy!")

I followed Bryan's link to the Haskell/OSCon-related blog posts at Technorati. Here's an interesting one by chromatic, who gave some Perl talks at OSCon. Favorite quote:

I sat next to Nat Torkington at the tutorial. He kept rubbing his temples. At one point I leaned over and said, “The interesting thing about Haskell is that its functions only take one argument.” He turned green.

In all seriousness, well-factored Haskell code resembles well-factored Smalltalk code: if you have functions (or methods) longer than a handful of lines, you’re probably doing too much. Lower level languages such as C rarely give the opportunity for composition and abstraction that you can get out of functional languages. The presence of pure functions–functions which never change global state and which return the same output for the same input–is also immensely important.

It’s actually the combination of the two features which give these languages such power. When Haskell forces you to mark impure functions explicitly, it gives you tools to isolate behavior which can change global state in the smallest possible scopes, and prevents you from composing impure and pure code together accidentally. When Haskell lets you compose functions into larger functions, not only does it help you write code more concisely, but it provides well-defined units of behavior which work along well-defined and isolated boundaries.

So what is this business about Haskell functions taking only one argument? Let's look at a quick example. Say I wanted to write a function to multiply two numbers. I'd write:

mul a b = a * b

I could give the type of this function like this:

mul :: Int -> Int -> Int

You could read that as "mul takes two Ints and returns an Int". And you can think of it this way. But you could also write the type this way:

mul :: Int -> (Int -> Int)

It means the exact same thing and is valid to Haskell. To read it, you'd say "mul takes an Int and returns a function that takes an Int and returns an Int." And truly this is what Haskell functions that take multiple parameters are doing. Now, I can say:

fifteen = mul 3 5

mulByThree = mul 3

fifteen' = mulByThree 5

fifteen'' = (mul 3) 5

mulByThree has type Int -> Int; it's a function that we got by simply not applying "mul" to all its arguments. fifteen'' illustrates what is going on internally when you write "mul 3 5". It turns out that being able to call a function with multiple arguments is just some syntactic sugar to Haskell.

This is a tremendously useful feature. For instance:

filter (>= 10) [1..20]

I've applied >= to only one argument here. That's fine; it returns a function that's exactly what filter wants.

I've been watching the video of Simon's Taste of Haskell talk. I could *hear* when the audience grasped the utility of this because there was a collective "Oooooo!" from them.

By the way, Haskell has type inference, so I didn't have to give types at all. Oh, and you can also refer to the function itself by not giving any arguments.

mul = (*)

This is one small reason I like to say "Haskell manipulates functions with the same ease that Perl manipulates strings." Mind-bending, isn't it?

Mozilla switching to Mercurial

nospam@example.com (John Goerzen) — Fri, 13 Apr 2007 18:36:00 -0500

There was some news yesterday: Mozilla is adopting Mercurial. The article has some insight into their reasons for picking Mercurial as well. (The comments they make about the CVS conversion process perhaps reference tailor, convert-repo, or cvs2hg; Mercurial proper doesn't have a built-in CVS importer)

Some more git, mercurial, and darcs

nospam@example.com (John Goerzen) — Mon, 26 Mar 2007 06:14:00 -0500

Ted Ts'o had an interesting post about git recently. He has a lot of good thoughts on the subject. He comments that he wound up using git because it's so Unixy (with its small commands to do things), that he sees the git community developing innovations faster than Mercurial, and that they are working to improve the documentation and user interface problems.

The being so Unixy is a double-edged sword. On the one hand, it can make it easy to write shell scripts to extend Git. That itself can be a double-edged sword (think filename quoting and the like). But one doesn't have to use the shell. The other downside is that being Unixy makes it hard to run on platforms that aren't, such as Windows. So if one is working on Unix-only software (X, the kernel, e2fsprogs, etc.), there's no need to care about it. But if you're a person like me, who has Windows users using my software, or a large organization like Mozilla, it's maybe a showstopper. Of course, workarounds exist (cygwin, git-cvsserver), but none of them are particularly nice.

I think that both Git and Mercurial are working to address their shortcomings. I've chosen hg for now because it does what I need now. And because there are very nice tools to convert hg to git, and vice-versa. So if Ted's right, and a year from now git is easier to use, better documented, more featureful, and runs well on Windows, it won't be that hard to switch over and preserve history. Ted's the sort of person that usually is right, so maybe I should starting looking at hg2git right now

So following up on my bzr post, here are the things that Mercurial is great at right now:

Performance. Approximately even with git, occasionally faster. Nobody else can compete with these two right now.
Simplicity. It's almost as easy to get started as with darcs, and with recent patches, will be even closer in the future.
Lots of ways to interact. You can send hg bundles, which preserve all metadata (parents, hash, authors, etc), or you can send git-format email patches, or you can push and pull between repos. The email tools will shortly be able to automatically detect what patches to send. Your choice. git doesn't seem to support lossless emailing of bundles like this, and bzr doesn't make emailing of anything easy by default.
Merging. hg seems to be able to automatically resolve more merge conflicts than anything else, and when it can't automatically resolve them, has a nicely configurable system to let you use your choice of tool to manually resolve them.
Community. The Mercurial community is open and inviting, and open to new/different ideas. It seems similar to Darcs in that respect, and somewhat dissimilar to git.
Rebase does not trash history like it does (barring undocumented manual intervention) in git.

I've written before about Darcs, so I won't duplicate that here.

bzr, again

nospam@example.com (John Goerzen) — Fri, 23 Mar 2007 04:38:00 -0500

I've talked a lot lately about different VCSs.

I got some interesting comments in reply to my most recent post. One person took issue with my complaint that nobody really understood how to specify a revision to git format-patch, and proceeded to issue an incorrect suggestion. And a couple of people complained about my comments about bzr, which generally came down to the released version of bzr didn't have anything compelling and also didn't support tags.

So I went into #bzr, asked them what bzr has that git, Mercurial, and darcs don't. And gave bzr the benefit of the doubt that 0.15 will be out soon and will be stable. What I got back were these general items:

Renaming of directories (not in hg, git)
2-way sync with Subversion (not in hg, darcs)
Checkouts (not in any others by default)
No server-side push requirement

Let's look at these in more detail.

1. Renaming of directories

All of them can rename files and (excepting git) completely accurately track back the file's history. But consider this: if person A commits a change to branch A that adds a file, and person B then renames the directory that the file is in on his branch, will a merge cause person A's file to appear in the new directory name? In darcs and bzr, yes. In Mercurial and git, no.

So yes, this is a nice thing. But I have never actually had this situation crop up in practice, and even if it did, could be trivially remedied. I would say that for me, I don't really care.

[Update: Current stable releases of Mercurial can do this too. I'm not quite sure how, but it does work. So git is the only one that can't do that.]

2. 2-way sync with Subversion

This is a really nice feature and is present in both git and bzr. I haven't tested it either place, but if it works as advertised -- and properly supports tracking multiple related svn branches and merges -- would be slick. That was enough to make me consider using git, but in retrospect, I so rarely interact with people using svn that it is not that big a deal to me.

Still, for those that have to work with svn users, this feature in bzr and git could be a big one.

Better yet would be to get all those svn holdouts over to DVCS.

3. Checkouts

A bzr checkout is basically a way to make local commits be pushed to the remote repo immediately, as with svn. This is of no utility to me, though I can see some may have a use for it. But it can be done with hg hooks and probably approximated with scripting in others.

4. No server-side process necessary for pushing repos

bzr has built-in support to push to a server that has sftp only, and doesn't require a copy of itself on the server. While I believe that none of the other three have that, it is possible to rsync (and probably ftp) darcs and Mercurial repos to a server in a safe fashion by moving repo files in a defined order. Probably also possible with git. All four can pull repos using nothing but regular HTTP.

What bzr still doesn't have

Integrated patch emailing. The big thing is that it has no built-in emailing of patches support. darcs is extremely strong in this area, followed by hg, and git is probably third. "darcs send" is all it takes to have darcs look at the remote repo, figure out what you have that they don't, and e-mail a bundle of changesets to them. I posted an extension and later a patchset that does all this for Mercurial except for automatically figuring out what default email address to do (that'll come in a few days, I think). One feature Mercurial has had for awhile that Darcs hasn't is sending multiple textual diffs as a thread, with one message per changeset. bzr doesn't have any support for emailing patches yet, which is disappointing. Because of the strong support for this in darcs and Mercurial, people running those systems feel less of a need to publish their repos.

[Update: There is a plugin for bzr that seems to address some of this. I haven't tested it, and it's not in bzr core (so doesn't quite meet my very friendly for a newbie requirement), but this does exist, though apparently not as advanced as Mercurial]

Performance. Supposedly 0.15 is supposed to be better on this, but even if bzr achieves the claimed doubling of performance, most benchmarks I have seen would rate it as still being significantly behind git and Mercurial, though it may overtake darcs in some tests.

Extensive documentation. I would say that bzr's docs are better in some ways than git's (its tutorials especially), but lack depth. If you want to know some detail about how the repository works on-disk, it's not really documented. Darcs still has David's excellent manual, and Mercurial has the hg book which is still great as well.

Merging not as advanced. darcs is pretty obviously way on top here, but of the others, Mercurial does a pretty good job with its automatic handling of renames and automatic resolving of different branches that commit the same change (even if that same change is a rename, or an add of the same content). bzr can't resolve as much automatically.

Summary

Well, I'll say that bzr still doesn't look compelling enough for my use cases to use, and the lack of an easy-for-a-newbie-to-use automated email submission feature is a pretty big disappointment. Though I did appreciate the time those on #bzr spent with me, and if I needed to sync with svn users frequently, I'd probably choose bzr over git.

For now, I'm happy with sticking with darcs for my code and hg for my Debian work.

But all four communities are aggressively working on their weaknesses, and this landscape may look very different in a year.

More on Git, Mercurial, and Bzr

nospam@example.com (John Goerzen) — Thu, 22 Mar 2007 05:25:00 -0500

I've been writing a lot about this lately, I know, but it's an interesting landscape.

I had previously discarded git, but in light of git-cvsserver (which provides a plausible way for Windows people to participate), I gave it a try.

The first thing I noticed is that git documentation, in general, is really poor. Some tutorials that claim to cover git actually cover cogito. Still others use commands that are much more complex than those in the current git -- and these just the ones linked to from the git homepage.

git's manpages aren't much better. There are quite a few git commands (such as log) that take arguments that other git commands accept. Sometimes this fact is documented with a pointer to these other commands, but often not; a person is left guessing what the full range of accepted arguments are.

My complaint that git is overly complex still exists. They've made progress, but still have a serious issue here. Part is because of the docuemtnation, and part is because of the interface. I wanted to export to diffs all patches on the current branch in a repo. I asked on #git, and someone suggested using the revision specifier ..HEAD. Nope, didn't work. A few other git experts chimed in, and none could come up with the correct recipe. I finally used -500, which worked but is hackish.

git's lack of even offering support for a human to indicate renames also bothers me, though trustworthy people have assured me that it doesn't generally cause a problem in practice.

git does have nicer intra-repo branching than Mercurial does, for the moment. But the Mercurial folks are working on that anyway, and branching to new directories still works fine for me.

But in general, git's philosophy is to make things easy for the upstream maintainer, and doesn't spend much effort making things easy for contributors (except to make it mildly easier to contribute to a large project like Linux). Most of my software doesn't have a large developer community, and I want to make it as easy as possible for new developers to join in and participate. git still utterly fails on that.

I tried bzr again. It seems that every time I try it, after just a few minutes, I am repulsed. This time, I stopped when I realized that bzr doesn't support tags and has no support for emailing changesets whatsoever. As someone that has really liked darcs send (and even used tags way back with CVS!), this is alarming. The tutorial on the bzr website referenced a command "bzr help topics", which does not work.

So I'll stick with my mercurial and darcs combination for now.

I announced the first version of a hg send extension yesterday as well. I think Mercurial is very close to having a working equivalent to darcs send.