Hacker News new | ask | show | jobs
by panic 3744 days ago
Distributed version control wasn't Linus's idea. BitKeeper, Arch, Monotone and darcs did it first, and in some ways better. But they all had problems: BitKeeper was proprietary, Arch was baroque and difficult to use, and Monotone and darcs had poor performance (darcs egregiously so, with an unfortunately-easy-to-hit exponential-time edge case in their merging algorithm). Using Git was a vote against these systems. But there's also not as much of a DVCS monoculture: Bazaar and Mercurial are also used quite often, and could be adopted quickly if git were to implode for some reason.
3 comments

Arch also had terrible performance. The primary objects that lived in repositories were changesets, which every client downloaded as .tgz files IIRC, and then replayed locally to reach the current state.

The primary innovation of both git and Mercurial was performance. Git is a highly optimized content-addressable database with version control built on top.

Arch was baroque and difficult to use

More than git? I shudder at the thought.

Well, just to give you a taste, here's an excerpt from "Revision Control with Arch: Introduction to Arch" in Linux Journal (http://www.linuxjournal.com/article/7671):

In Arch, a changeset is represented as a directory tree full of bookkeeping files, patches, new files and removed files. The best contribution technique is to create a changeset directory and then tar it up for delivery:

    $ tla changes -o ,,new-robot-comment
    $ tar czvf my-changes.tar.gz ,,new-robot-comment/
Arch ignores files beginning with two commas, an equal sign and a few other special characters. By using a ,, at the start of our changeset directory name, we avoid the annoyance of Arch complaining that our new directory doesn't exist in the archive. It is probably good practice to use your e-mail address or some other identifier in the tarball filename and changeset directory name.
I thought it was just me. Anything more than the basic commands and I get confused and have to look it up. Git is certainly popular -perhaps for many it's the first version control system they've used-and is very fast, but would you say it's well designed from a user perspective?
No, git is a UI disaster. Some of the complexity is necessary due to moving to a distributed model of version control, but most of it is lack of clarity in designing the CLI.

Is anyone who's used Mercurial able to comment on the UI differences?

Bitkeeper was first among the DVCS's, but Linus had a hand in its design. McVoy intentionally designed something to fit the (decentralised) Linux development process. The adoption of Bitkeeper for Linux and subsequent discussions gave rise to the cambrian explosion of Arch(/TLA/Bzr), Monotone, Darcs etc in the early 00s.

The famous two weeks time off to write git was many years later, when tridge finally forced his hand to do it. I don't think it's quite right to say git was a vote against anything else (except maybe against C++, which would bring some maintenance problems in the kernel community).