Bazaar unsuitable for Emacs's ELPA branch

[Stefan Monnier]

We've been using Bzr for Emacs's source code for several years now, and
while we've had plenty of endless threads asking why we keep using it
instead of Git, it has served us acceptably (not super efficiently, but
not significantly worse than back in the CVS days).

A couple years ago we started setting up a new branch (called `elpa')
which holds Elisp packages that are not distributed with Emacs, but can
be easily installed via a package manager UI.

This branch should ideally be using something like "config-manager"
since it's really a combination of separate projects.  But we have it as
a Bzr branch because config-manager isn't good enough yet (e.g. isn't
able to handle removals).

Some of the projects it contains use this `elpa' branch as the canonical
source, while others store their canonical code elsewhere, which is then
treated as an upstream branch from which we merge "regularly".

In theory this should work OK, but in practice it is becoming clear it
can't be used:
- revision 171 bumped into a bug of Bzr which has something to do with
  rich-root.  So now you can't just "bzr co .../elpa" but need to do it
  in two steps: "bzr co -r170 .../elpa" and then "bzr update".
  For one of the public branches of the Emacs project, this is a major
  pain in the youknowwhat.
  This bug has been reported a long while ago but shows no sign of
  getting fixed.
- several of the externally maintained packages use Git, so we track
  them via "bzr-git".  But "bzr-git" always uses the same ID for the
  root node, so we can't just "bzr co .../foo.git foo; bzr join foo"
  since the ID used for `foo' is already used.  We end up having to play
  a little dance where we "bzr co .../foo.git foo" then "bzr mv"
  everything into a subdir, then "bzr split" this subdir and then "bzr
  join" the result into `elpa' (where the "move + split" ends up
  generating a new ID for the split tree's root, hence solving the
  problem).
  This makes it tricky to add new packages, and also makes tracking
  those packages more painful since merges report conflicts whenever the
  upstream has added/removed files.

For these reasons, we're looking at moving the `elpa' branch to some
other revision control.


        Stefan