"bzr branch lp:projectname" fails in a strange way

[Michael Hudson-Doyle]

Doing something like this:

$ bzr branch lp:bzr-svn

fails in a rather mysterious way:

$ bzr branch lp:bzr-svn
http://code.launchpad.net/bzr-svn/ is redirected to https://code.launchpad.net/bzr-svn/
bzr: ERROR: Transport operation not possible: http does not support mkdir()

"bzr branch lp:bzr-svn bzr-svn" works fine though.

[John A Meinel (jameinel)]

It happens because "lp:bzr-svn" doesn't have a path separator ('/'). So
  bzr branch lp:///bzr-svn

should work correctly.

2 possible fixes are:

1) At least give a better error and display what branch you are trying to branch to, and why you cannot.
2) Update the code to directly recognize "lp:" and strip it. Either by refactoring over the Transport object (since lp: is a non-standard url scheme, all of our other schemes are foo:// at least).

[Andrew Bennetts (spiv)]

I don't think fix 1 is good enough. It's possibly a worthwhile fix, but for a separate bug than what I consider to be the main bug here, which is that "bzr branch lp:foo" should Just Work.

Fix 2 (teaching the code to handle "lp:" URLs better) would be the right thing, I think. I don't know if hard-coding it for the "lp:" scheme or something more general is better. Be sure to remember that URLs like "lp:python/2.4" are valid (although that particular one isn't as of today).

[Bubba Siggler (bud3)]

Things are save an easy yea. I have a lot of *?* but The one I really get lost on is the Doc do and don't.

See Attach . I don't know what a *hunk* is missing. The file Eclipse I made to start a txt file for eclipse.

[John A Meinel (jameinel)]

Well, as we are asking it, what should 'bzr branch lp:python/2.4" *do* ?

One of the things we considered, was to allow the Transport to normalize the URL, and then use the base of the normalized version.

But that would mean "bzr branch lp:python" would normalize to http://bazaar.launchpad.net/~vcs-imports/python/trunk which would then create a 'trunk' directory on the local filesystem, rather than the expected 'python'.

And what to do in the case of "lp:python/2.4" or "lp:~jameinel/bzr/dirstate-optim" (the latter of which does work).

As of right now, "lp:python/2.4" would create "2.4" and the latter "dirstate-optim". Which seems reasonably correct.

Another possible (easy) fix would be to change "lp:" to always require at least one '/'. So we would have "lp:/python"

I really don't like special casing 'lp:' in branch and checkout (which is another possible fix).

We could do something special with ':' (so that we split on either '/' or ':'), but I believe "http://foo/bar:baz" is a valid url. And could create 'bar:baz" on Linux. (I think on Windows it would bork, and on Mac it would be treated as '/' in the main explorer)

[Steve Alexander (stevea)]

Simply having a decent error message would fix this for now. There is no need to have an elaborate heuristic for what directory to create.

I just ran into this error, and I had no idea whether I'd used it correctly. I had to ask for help to make it work.

If the error message told me "you must give a target directory", then I'd have had no problem at all.

Raising this to a critical priority, because it will totally put new users off using the bzr launchpad integration.

[Steve Alexander (stevea)]

This is a critical problem because this is the first step in a new user trying out bzr-launchpad integration, and it fails in a way that discourages them from trying further. A better error message would fix this problem.

[Bubba Siggler (bud3)]

Hi everyone,

bubba@bubba-desktop:~$ bzr selftest
       bzr: /usr/bin/bzr
    bzrlib: /usr/lib/python2.5/site-packages/bzrlib

/usr/lib/python2.5/site-packages/bzrlib/transport/ftp.py:785: UserWarning:
You must install medusa (http://www.amk.ca/python/code/medusa.html) for FTP
tests
  warn("You must install medusa (http://www.amk.ca/python/code/medusa.html)
for FTP tests")
[1223/6747 in 70s, 6 skipped, 1 missing features]
test_permissions.TestSftpPerm/var/lib/python-support/python2.5/paramiko/message.py:226:
DeprecationWarning: integer argument expected, got float
  self.packet.write(struct.pack('>I', n))
[4497/6747 in 299s, 254 skipped, 1 missing features]
branch_implementations.tes/usr/lib/python2.5/site-packages/bzrlib/lockable_files.py:110:
UserWarning: file group LockableFiles(<
bzrlib.transport.remote.RemoteTransporturl=bzr://127.0.0.1:54025/b/.bzr/repository/>)
was not explicitly unlocked
  warn("file group %r was not explicitly unlocked" % self)
[4501/6747 in 299s, 254 skipped, 1 missing features]
branch_implementations.tes/usr/lib/python2.5/site-packages/bzrlib/lockable_files.py:110:
UserWarning: file group LockableFiles(<
bzrlib.transport.remote.RemoteTransporturl=bzr://127.0.0.1:57725/b/.bzr/repository/>)
was not explicitly unlocked
  warn("file group %r was not explicitly unlocked" % self)
[6722/6747 in 448s, 472 skipped, 1 missing features]
bzrlib.plugins.bzrtools.te1 out of 1 hunk FAILED -- saving rejects to file
test_file.rej
[6747/6747 in 451s, 472 skipped, 1 missing features]
bzrlib.plugins.bzrtools.te
----------------------------------------------------------------------
Ran 6747 tests in 451.482s

OK
472 tests skipped
Missing feature 'medusa' skipped 1 tests.
bubba@bubba-desktop:~$

I hope this is what you need Steve

best regards

bubba

On 5/30/07, Steve Alexander <email address hidden> wrote:
>
> Simply having a decent error message would fix this for now. There is
> no need to have an elaborate heuristic for what directory to create.
>
> I just ran into this error, and I had no idea whether I'd used it
> correctly. I had to ask for help to make it work.
>
> If the error message told me "you must give a target directory", then
> I'd have had no problem at all.
>
> Raising this to a critical priority, because it will totally put new
> users off using the bzr launchpad integration.
>
> --
> "bzr branch lp:projectname" fails in a strange way
> https://bugs.launchpad.net/bugs/115491
> You received this bug notification because you are a member of Bazaar
> Developers, which is the registrant for Bazaar.
>

--
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFkcN7yXWcajQQndYRAgbqAKCMyXN9Jx4g0X7jocg+aUSFz0x4LwCgrURW
eGtqLjpzQVYa9+gzpCRtB84=
=zrpM
-----END PGP SIGNATURE-----

[Ian Clatworthy (ian-clatworthy)]

I agree with Andrew Bennett here. It was just as much work to trap the case and put out a good message as it was to do the Right Thing, so I implemented the latter in a patch sent to the mailing list. As a side benefit, slightly more correct handling of some Windows/DOS filenames is delivered by the code as well.

[John A Meinel (jameinel)]

This fix has been in Bazaar since 0.17 (urlutils.derive_to_location)