New launchpad policy to store parent URL as %2Bbranch breaks smart creation of default URL for qpush

[Alexander Belchenko]

We have to find the way to workaround this inside QBzr.

If you get a branch from launchpad and then create separate local branch from that mirro to work on some changes to project and then you try to push your changes back, qpush trying to suggest you new URL based on the name of your new branch and the parent of the mirror. But now launchpad stores parent URLs as:

bzr+ssh://bazaar.launchpad.net/%2Bbranch/bzr/2.3/

So qpush tries only to change the last part of URL.

Now qpush propose me the following URL to push:

bzr+ssh://bazaar.launchpad.net/%2Bbranch/bzr/test

Attempt to push to this URL failed:

Run command: bzr push bzr+ssh://bazaar.launchpad.net/%2Bbranch/bzr/test
Connected (version 2.0, client Twisted)
Authentication (publickey) successful!
Secsh channel 1 opened.
bzr: ERROR: Permission denied: "Cannot create 'test'. Only Bazaar branches are allowed."

[Alexander Belchenko (bialix)]

I think we can try to detect bzr+ssh://bazaar.launchpad.net/%2Bbranch and replace %2Bbranch with launchpad_login from bazaar.conf

[Alexander Belchenko (bialix)]

Err, sorry, launchpad_username

[Max Bowsher (maxb)]

If you autodetect bazaar.launchpad.net/+branch/ URLs, you should bear in mind that they can have five forms:

+branch/bzr <--- a project's development focus branch
+branch/bzr/2.3 <--- a project's non-focus series branch
+branch/ubuntu/base-files <--- a source package within the current development series of a distro
+branch/debian/sid/base-files <--- a source package within a named series of a distro
+branch/ubuntu/lucid-updates/base-files <--- a source package within a named non-release pocket of a distro

In each of these cases, a smart enough "where to push back" guesser would guess:

~user/bzr/foobar # Replace +branch with ~user
~user/bzr/foobar # Replace +branch with ~user, chop series id
~user/ubuntu/natty/base-files/foobar # Replace +branch with ~user, insert name of current dev distro series, or placeholder
~user/debian/sid/base-files/foobar # Replace +branch with ~user
~user/ubuntu/lucid/base-files/foobar # Replace +branch with ~user, chop "-pocket" suffix from series id

[Gordon Tyler (doxxx)]

This may be off-topic for this bug, but I dislike how the resolved URL of lp:foo is stored in branch.conf. If the lp:foo URI were stored in the branch.conf then this wouldn't be a problem.

[Martin Pool (mbp)]

On 1 February 2011 15:31, Gordon Tyler <email address hidden> wrote:
> This may be off-topic for this bug, but I dislike how the resolved URL
> of lp:foo is stored in branch.conf. If the lp:foo URI were stored in the
> branch.conf then this wouldn't be a problem.

I agree; that would be much better.

[Alexander Belchenko (bialix)]

Gordon Tyler пишет:
> This may be off-topic for this bug, but I dislike how the resolved URL
> of lp:foo is stored in branch.conf. If the lp:foo URI were stored in the
> branch.conf then this wouldn't be a problem.

I disagree. In the case of lp:foo we unable to create new URL easily.

--
All the dude wanted was his rug back

[Martin Pool (mbp)]

On 1 February 2011 18:21, Alexander Belchenko <email address hidden> wrote:
> Gordon Tyler пишет:
>> This may be off-topic for this bug, but I dislike how the resolved URL
>> of lp:foo is stored in branch.conf. If the lp:foo URI were stored in the
>> branch.conf then this wouldn't be a problem.
>
> I disagree. In the case of lp:foo we unable to create new URL easily.

What do you mean?

[Vincent Ladeuil (vila)]

    > This may be off-topic for this bug, but I dislike how the resolved URL
    > of lp:foo is stored in branch.conf. If the lp:foo URI were stored in the
    > branch.conf then this wouldn't be a problem.

We could also store *both* URLs, the unresolved (provided by the user,
in this case the lp one) and the resolved one.

There will be fallouts though...

[Alexander Belchenko (bialix)]

Martin Pool пишет:
> On 1 February 2011 18:21, Alexander Belchenko <email address hidden> wrote:
>> Gordon Tyler пишет:
>>> This may be off-topic for this bug, but I dislike how the resolved URL
>>> of lp:foo is stored in branch.conf. If the lp:foo URI were stored in the
>>> branch.conf then this wouldn't be a problem.
>> I disagree. In the case of lp:foo we unable to create new URL easily.
>
> What do you mean?

I don't know yet.

Look:
http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk2a/view/head:/lib/pull.py#L182

This method returns empty string now, so we have to fallback to generic
URL suggestion.

--
All the dude wanted was his rug back

[Alexander Belchenko (bialix)]

Indeed, the problem in the %2Bbranch. Our code expects to get instead ~user-id. So we only need teach it new tricks.

[Alexander Belchenko (bialix)]

Martin Pool пишет:
> On 1 February 2011 18:21, Alexander Belchenko <email address hidden> wrote:
>> Gordon Tyler пишет:
>>> This may be off-topic for this bug, but I dislike how the resolved URL
>>> of lp:foo is stored in branch.conf. If the lp:foo URI were stored in the
>>> branch.conf then this wouldn't be a problem.
>> I disagree. In the case of lp:foo we unable to create new URL easily.
>
> What do you mean?
>
Current code uses full URL like
bzr+ssh://bazaar.launchpad.net/~user-id/project/branch

to create new URL like:

lp:~user-id/project/new-branch

--
All the dude wanted was his rug back

[Gordon Tyler (doxxx)]

But if the original URI given is lp:~user-id/project/orig-branch, then it should be easy to create the URI for a new branch. My point is that the lp URI is a simpler, yet sufficient, description of the branch location that is more easily introspectable and manipulable. The resolved URL is essentially an implementation detail of the Launchpad interaction. The user doesn't care about the resolved URL. The only thing that does care is the code which actually has to make the connection to the remote branch. Everything else should deal with the lp URI, i.e. the canonical form of the branch location.