bzr push --use-existing-dir fails poorly on non-extant series branches

This occurs both with bzr 2.3b3 and with bzr trunk (as of 2010-11-17).

Envoie moi un bzr diff, on va fonctionner comme ça pour l'instant, tant
pis.

A+
Franck

Le 17/11/2010 09:36, Luca Saiu a écrit :
> This occurs both with bzr 2.3b3 and with bzr trunk (as of 2010-11-17).
>

I've found a reliable workaround: the thing works if I create a
branch explicitly owned by me (and *not* by the team to which I
belong and which should normally own the branch). In this example
my username is saiu and my team is marionnet-drivers; I want to
make a branch called 0.90.x, owned by marionnet-drivers .

First of all, I login:
bzr launchpad-login saiu

This works:
bzr push --verbose lp:~saiu/ocamlbricks/0.90.x

After creating the branch like that, I can change its ownership with
launchpad, and attach it to a release series.

Instead if I simply do
bzr push --verbose lp:ocamlbricks/0.90.x
I observe the behavior reported by Vadim Nevorotin. Vadim, is your
situation similar?

Anyway, this definitely *is* a bug. Even if according to the intended
semantics I weren't allowed to make a branch owned by my team (but why
shouldn't I be able to?), I think that
Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
is a pretty bad way of signaling the error condition.

I think the problem here is that if the branch does not yet exist,
Launchpad doesn't know who ought to own the branch when you attempt to
push to it?

The 'maximum recursion error' is of course not the intended way to
report this, but rather a side effect of this, or perhaps some
unrelated issue. It's just noise, not an error.
--
Martin

In response to Martin Pool:
 I think you'r right about that, the fact that the branch owner is not specified may well be the cause (didn't I specify that the code is owned by marionnet-drivers by default somewhere? Mmm, I'm not so sure anymore; maybe there isn't a default...).
In fact I've just noticed that making a branch *explicitly* owned by the team with bzr works:

bzr push --verbose lp:~marionnet-drivers/ocamlbricks/booboo

And I can also make several branches in the same project with identical names, and different owners:

bzr push --verbose lp:~saiu/ocamlbricks/booboo
bzr push --verbose lp:~marionnet-dev/ocamlbricks/booboo

I wasn't expecting this, because often we pull, merge or get from branches with an unspecified owner. This has always worked:

bzr get --verbose lp:ocamlbricks/trunk

Yet, this doesn't work when there are three booboo branches:

bzr get --verbose lp:ocamlbricks/booboo
/usr/lib/python2.6/dist-packages/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases. See http://www.pycrypto.org/randpool-broken
  RandomPool_DeprecationWarning)
bzr: ERROR: Permission denied: "Cannot create 'booboo'. Only Bazaar branches are allowed."

I delete two booboo branches from Launchpad, the ones owned by marionnet-drivers and marionnet-dev; the branch owned by saiu still exist, and I try to refer to it without specifying an owner. No luck:

bzr get --verbose lp:ocamlbricks/booboo
/usr/lib/python2.6/dist-packages/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases. See http://www.pycrypto.org/randpool-broken
  RandomPool_DeprecationWarning)
bzr: ERROR: Permission denied: "Cannot create 'booboo'. Only Bazaar branches are allowed."

The same happens if I only leave the booboo branch owned by marionnet-drivers. But then why is trunk, which I can get without specifying an owner, different?

Again, specifying the owner works:
bzr get --verbose lp:~saiu/ocamlbricks/booboo

Of course I know that "maximum recursion depth exceeded" wasn't intended as a direct response to the specific error condition; I was being sarcastic which was not a constructive reaction. I apologize for that -- but I assure you that the situation was pretty frustrating. Also look at the message above: I think that "Cannot create 'booboo'. Only Bazaar branches are allowed." is also a quite bad error message for a *get* failure where the branch indeed exists (even more than one!).

I like bzr but I think it can be made friendlier.

By the way, I'm Luca Saiu; I also was at the GHM in Den Haag, but I don't think we spoke; happy to meet another GNU guy.
And sorry again.

Hi Luca,

Basically this is a usability bug in the handling of 'short' urls on Launchpad. Really they are just aliases for a full url like say lp:~saiu/ocamlbricks/booboo. If the alias already exists, bzr can push to it. If it does not, you get a confusing message. To set the default branch for the project or release series, you must use the lp web ui or the Launchpad webservices api.

1- we could at least give a better message
2- where the product/series exists, perhaps pushing to it should create a branch with an appropriate default owner
3- if the product exists, pushing to a new series could also just create a series object (less sure about this)

The workaround doesn't work for me though:
Bazaar 2.2.1
akuzminsky@ubuntu:~/src/release-5.1.52-11$ bzr launchpad-login
akuzminsky
akuzminsky@ubuntu:~/src/release-5.1.52-11$ bzr push --verbose lp:~akuzminsky/percona-server/release-5.1.53-11 --use-existing-dir
Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored

On 2 December 2010 23:35, Aleksandr Kuzminsky <email address hidden> wrote:
> The workaround doesn't work for me though:
> Bazaar 2.2.1
> akuzminsky@ubuntu:~/src/release-5.1.52-11$ bzr launchpad-login
> akuzminsky
> akuzminsky@ubuntu:~/src/release-5.1.52-11$ bzr push --verbose lp:~akuzminsky/percona-server/release-5.1.53-11 --use-existing-dir
> Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
> Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored

And did that ultimately work, or fail? I see the branch does not
exist at the moment.

If it failed, did you get any other error, or a traceback in .bzr.log?

--
Martin

This bug has two components I think - creating series branches by pushing (There is a separate bug for that), and 'bzr push --verbose lp:~akuzminsky/percona-server/release-5.1.53-11 --use-existing-dir' failing. Lets focus on the command failing here.

It looks like bzr is emitting the errors, so adding a bzr task.