Can't checkout Emacs's ELPA repository

[Stefan Monnier]

Trying "bzr co bzr://bzr.sv.gnu.org/emacs/elpa" fails with the following error:
bzr: ERROR: exceptions.AssertionError: ('not present: %r', StaticTuple('', '', 'TREE_ROOT'))

It seems this is due to revno 171 where I did a "bzr join" of "bzr-git" tree.
More specifically, "bzr co -r 171 bzr://bzr.sv.gnu.org/emacs/elpa" fails with the same error, whereas "bzr co -r 170 bzr://bzr.sv.gnu.org/emacs/elpa" succeeds without any problem.

The tests are done from a Debian testing machine running Debian's bzr-2.5.0dev6.

How can we recover from this problem?

[Stefan Monnier (monnier)]

See http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/73724 for additional info, in case it is difficult to reproduce.

[Stefan Monnier (monnier)]

I recently noticed that the head can be checked out in two steps:
"bzr checkout -r170 bzr://bzr.sv.gnu.org/emacs/elpa" followed by "bzr update".
So apparently the repository is not really broken, but triggers a bug in Bzr.

[Jelmer Vernooij (jelmer)]

> I recently noticed that the head can be checked out in two steps:
> "bzr checkout -r170 bzr://bzr.sv.gnu.org/emacs/elpa" followed by "bzr update".
> So apparently the repository is not really broken, but triggers a bug in Bzr.
I think it's a bit of both. The repository doesn't have that particular node, that's why things fall over.

However, the fetch code in bzr (used by "bzr up") has support for checking for and adding this particular node (and this node only) to deal with upgrades from non-rich-root to rich-root formats.

(unassigning myself since you've managed to recover from this problem)

[Stefan Monnier (monnier)]

While we can check it out now, it's still a pretty serious problem, since it is a very public branch where such a workaround is problematic for many people.

[Jelmer Vernooij (jelmer)]

Am 24/03/12 14:36, schrieb Stefan Monnier:
> While we can check it out now, it's still a pretty serious problem,
> since it is a very public branch where such a workaround is problematic
> for many people.
If you've updated it this way once (which has added the problematic
entry), you should then be able to replace the upstream copy with the
fixed copy. Have you tried this?

Cheers,

Jelmer

[Stefan Monnier (monnier)]

> If you've updated it this way once (which has added the problematic
> entry), you should then be able to replace the upstream copy with the
> fixed copy. Have you tried this?

If I try to "bzr co" from my local branch (which I had to first checkout to -r170 and then to update to the latest revision), I get the same problem. Even a lightwieght checkout bumps into the problem. So the "added entry" that makes my local branch work, seems to be only present in the checkout but not in the branch/repository.

[cyd (seewhydee)]

Is there any further suggestion from the Bazaar devs about how to fix this problem? It is an extremely unsatisfactory situation.

[cyd (seewhydee)]

In particular, this comment

> (unassigning myself since you've managed to recover from this problem)

is extremely inaccurate---we have *not* managed to recover from this problem, since a "bzr branch" on this (very) public branch still causes bzr to fail. What is true is that there is a sequence of steps to take instead of a normal "bzr branch" that can allow the branch to be checked out, but we can hardly expect all users/developers to jump through these hoops.

[cyd (seewhydee)]

Ping.

The previous comments by Jelmer seems to imply that any bzr join will always cause this problem, unless the joined tree was previously created by bzr split. Is that true?

[tsdh (tassilo)]

Isn't this bug a duplicate of https://bugs.launchpad.net/bzr/+bug/830947?

There is a branch with a fix in the linked report.

[Stefan Monnier (monnier)]

bug#830947 provides a possible fix for this patch, but since it's not clear if/when it'll be installed, here's a simpler workaround that does not require you remember the magic revno 170:

 "bzr checkout .../elpa; cd elpa; rm -r *; bzr revert"