Bazaar

Bazaar

 




Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments

Canonical Ltd had a need for a decentralized version control system. At the time, the closest fit to their need was Tom Lord's GNU Arch, however there was some difficulty in adapting it to fit their exact needs.

Canonical worked on a branch of GNU Arch called Bazaar, or Baz.

After contributing a substantial amount to GNU Arch, it was felt that the existing codebase could not achieve the levels of performance or flexibility that was needed, so the team started work on a from-scratch implementation of what was called "Bazaar-NG", and is now known as Bazaar (Bzr for short).

Historically the project has had several names, but it is now just simply known as Bazaar. (See also Branding)

In early 2008, Bazaar became GNU Bazaar when release 1.2 was accepted as part of the GNU project.

Does Bazaar have anything in common with Baz 1.0?

JohnArbashMeinel writes

Bazaar 1.x was a fork of Gnu Arch (as tla), trying to make it a little bit easier to use. Gnu Arch was a semi-distributed SCM, which had some good ideas, and some bad ones. I say semi-distributed because it wasn't like darcs/bzr/hg/etc where each directory is a separate repository, it had a separate repository (called an archive) where everything was committed, but it was possible to go branch between archives while preserving enough information to allow future merging. It was patch focused (so every commit was a delta against the previous commit, not a snapshot like bzr).

Robert Collins was probably the leader of the Bazaar-1.x fork.

Anyway, Canonical was trying to get bazaar-1.x to support what it needed, and they came across some summaries that Martin had written, about the current SCMs. They liked what he had to say, and wanted him to start prototyping a new 'best-of-breed' SCM that could take what had been learned by all the projects.

Originally, I believe the idea was that bazaar-ng would evolve into a really nice python prototype, and when concepts had matured enough the bazaar-1.x C codebase would incorporate them. So eventually bazaar-1.x and bazaar-ng would actually converge to supporting the same branches, etc. At that point probably bazaar-1.x would actually become 2.0, and ng may or may not survive as a place for prototyping.

I'm not sure when the switchover came, but I think it was less than a year ago. When people realized that bazaar-ng was better enough that it wasn't worth trying to converge the two projects. Instead, you could upgrade bazaar-1.x to bazaar-ng, and go from there.

The things bzr inherited from bazaar/Gnu Arch:

1) file-ids, let us do a lot of really nice things like merge across renames. (In Arch you could actually apply a patch without having all of the ancestry, and it would find the right file. bzr technically supports that, but we never apply patches)

2) Dumb remote filesystem support. We can push to ftp/sftp/etc because the developers had come from Arch which had it, and wanted to keep that ability. Especially being able to pull from a plain HTTP location.

3) Developers. Aaron Bentley, Robert Collins, and myself all worked with the Bazaar/Gnu Arch code bases. Martin had used Gnu Arch, but I don't believe he ever hacked on it.

4) I'm sure there are more, but concepts have been plucked from lots of locations. (Like all the merge code descends from BaZing, which was a prototype that Aaron was working on, before bzr really got going)

Feel free to ask for more clarification. I've been around for a lot of it, but certainly not everything.

AaronBentley says

In early 2004, Canonical used GNU Arch as a revision control control system. Then they began working on a fork of GNU Arch called Bazaar (baz).

In November 2004, Canonical held a baz code sprint. Martin and I both attended, as non-employees. Martin was asked for advice on improving the user-friendliness of baz, and he concluded that architecture changes were required to make baz more user-friendly. He started designing the what he saw as the ideal system. It was believed that we could refactor baz into that system gradually.

Around January 2005, Martin began work on Bazaar-NG (bzr). The plan was that baz would incrementally adopt bzr's changes once proven. Bazaar-NG began to attract a following.

In the spring, John Meinel and I separately decided to stop working on baz and focus on bzr. I also began writing baz-import.

Later that year, baz was put into maintenance mode, and Robert Collins, who had been leading the baz effort, began contributing heavily to bzr.

There are definitely commonalities between baz and bzr:

  • files are identified by file-id
  • revisions have globally unique identifiers
  • both support a repository-and-checkout workflow
  • both use diff3-style merges
  • dumb file tranports (http, sftp, ftp, filesystem)
  • neither support tags
  • both support GPG signing

There are also some significant differences

  • uncommit is illegal (and dangerous) in baz
  • baz is written in C
  • baz has poor error messages (an improvement over Arch, though)
  • baz doesn't support the self-contained branches that bzr makes on init.
  • baz requires caches (revision libraries, tree logs and Arch Cache) for efficient operation (and is slow even so).
  • baz branches are referred to by globally-unique identifiers, not locations
  • baz branches typically do not have the complete revision-history. Instead, they say "look at this other branch for old data".