Branching/checking out "lp:~user/project/branch" URLs should use write-access if possible

Bug #121200 reported by Andrew Bennetts
4
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
High
Jonathan Lange

Bug Description

If I do "bzr branch lp:~me/proj/my-branch", I cannot do "bzr push" in that directory to push back to launchpad without spelling out the "sftp://bazaar.launchpad.net/..." URL in full, because it resolves the "lp:" URL to "http://...".

Similarly, if I do "bzr checkout lp...", it will checkout from the HTTP location, even if I have write access to that branch via SFTP.

It would be nice if the bzr-lp plugin automatically used write access to bazaar.launchpad.net when possible, so that I can always use "lp:" URLs.

This probably requires some minimal configuration to tell bzr-lp what my Launchpad username is. I propose adding a new command to the plugin:

    bzr lp-whoami USER

e.g.:

    bzr lp-whoami spiv

This is by analogy to "bzr whoami".

An alternative would be for the plugin to extend "bzr whoami" with a --lp option, but my gut feeling is that would be more confusing.

Tags: lp-code
Revision history for this message
Steve Alexander (stevea) wrote :

bzr whoami lp:spiv

perhaps.

Revision history for this message
Andrew Bennetts (spiv) wrote :

Steve suggests:

    bzr whoami lp:spiv

to set that piece of configuration. And further, suggests actually storing "lp:spiv" as the committer name to use in Bazaar. He explains that if people are collaborating using Launchpad, their Launchpad ID is a great way to find out what else that they are involved with.

I think it's an interesting idea, but probably too uncooperative to people and projects that don't use Launchpad. Even if we stored "https://launchpad.net/~spiv" rather than "lp:spiv" as the committer name in revisions (so that people that have never heard of Launchpad can at least have a good chance of understanding it), there's another problem: anyone viewing the revision history for commits with these committers would see a relatively opaque URL or ID, rather than the real name & email address they currently (usually) get. I suppose we could store "Andrew Bennetts <https://launchpad.net/~spiv>" in lieu of "Real Name <email>", but that still deprives other people of an easy opportunity to get in touch with me which is I think considered valuable in a decentralised version control world.

We already record user's email addresses in Launchpad, so when viewing a branch in Launchpad's UI, we ought to be able to automatically hyperlink committers with known email addresses. That would satisfy Steve's use case of finding out more about what a person has done in Launchpad without changing the metadata that bzr already tracks.

So I think I'm against "bzr whoami lp:spiv", although the idea of explicitly associating committers with Launchpad users is intriguing.

Revision history for this message
Robert Collins (lifeless) wrote :

I think that being able to say 'bzr whoami lp:spiv' is interesting for someone that wants to really into the collaboration options we're offering. That could resolve to their email address from launchpad - and thus we know who they are, still store good data in bzr - solves both issues AFAICT.

-Rob

Revision history for this message
Jonathan Lange (jml) wrote :

Lining up revision authors and Bazaar users would be very nice.

An alternative syntax is to offer 'whoami' as part of a Launchpad subcommand. So,
  $ bzr lp whoami jml
OR
  $ bzr launchpad whoami jml

How would the information be sent to Launchpad? I'm thinking either revision properties or some sort of XML-RPC method. Without thinking about it, I lean toward the former.

Revision history for this message
Stuart Bishop (stub) wrote :

Why is the default checkout http rather than anonymous bzr+ssh ? People stuck behind HTTP only firewalls are the minority. I would think if there is a config option, it would be to turn on branch-via-HTTP mode rather than specifying the username.

If the default protocol is ssh, then there is no need to store the Launchpad credentials in bzr preferences - Launchpad knows who you are already.

Revision history for this message
Jonathan Lange (jml) wrote :

Currently we don't offer bzr+ssh access at all -- it's coming soon. Shortly after that, we'll be allowing read-only access to all visible branches via bzr+ssh. As far as I'm aware, there are no plans to ever allow anonymous bzr+ssh access.

Even though SSH access removes the need to store LP credentials in Bazaar preferences, it might still be desirable to do so. As I meant to say, it would be very nice to be able to map revision authors to Launchpad users. If we could do that, we could track a user's activity in code, give karma for commits etc.

Revision history for this message
Jonathan Lange (jml) wrote :

I meant to say that once bzr+ssh support is up and running, it would probably make sense to make that the default.

Revision history for this message
Tim Penhey (thumper) wrote :

Also requires bzr patches, so won't be likely until bzr 0.93 at the earliest.

Server side updates should be in before the bzr client is released.

Changed in launchpad-bazaar:
assignee: nobody → jml
importance: Undecided → High
milestone: none → 1.1.11
status: New → Confirmed
Revision history for this message
Jonathan Lange (jml) wrote :

AIUI, we won't be running Bazaar 0.93 in LP 1.11.

Changed in launchpad-bazaar:
milestone: 1.1.11 → 1.1.12
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

I am confused by the status here.

The bazaar part of this has landed in bzr.dev, afaik. But the launchpad side has not.

So when I run bzr 0.92 against launchpad running now (1.10), things work more or less as I expect, I can pull any branch but not push to any, even the ones I own.

When I run bzr.dev against launchpad 1.10, it seems to always use sftp://bazaar.launchpad.net/~owner/project/branch, which doesn't work for branches I can't push to.

When I run bzr.dev against launchpad.dev, I get OOPSes.

(I don't think that there is a way of running bzr 0.92 against launchpad.dev).

So what's going on? The current state of play does not look particularly good, unless I'm doing something wrong at this end, but if I can't figure it out...

Revision history for this message
Jonathan Lange (jml) wrote :

Not sure about the OOPSes w/ bzr.dev vs launchpad.dev

Bazaar 0.92 doesn't have the associated changes.

bzr.dev requires you to specify your Launchpad login using 'bzr launchpad-login'. That it redirects to SFTP is a bug.

I've spoken with James and here's what needs to happen to close this bug:

Bazaar:
- Handle redirects when pushing to new branches.
- Factor out a needs_launchpad_login method and tell it that bzr+ssh and sftp Launchpad branches require LP logins.
- Improve the text of 'bzr help launchpad'

Launchpad:
- Don't offer SFTP as a branch location.

Revision history for this message
Jonathan Lange (jml) wrote :

There are patches up for review for:

Bazaar:
- Factor out a needs_launchpad_login method and tell it that bzr+ssh and sftp Launchpad branches require LP logins.
- Improve the text of 'bzr help launchpad'

Launchpad:
- Don't offer SFTP as a branch location.

Still need to do:
- Handle redirects when pushing to new branches.

Revision history for this message
Jonathan Lange (jml) wrote :

I've submitted the last patch "Handle redirects when pushing to new branches". It still needs one more positive review.

The Launchpad "don't offer SFTP" patch has been landed, as has the Bazaar documentation patch.

The "don't use SFTP without a launchpad-login" patch is in the process of being landed now, AIUI.

Jonathan Lange (jml)
Changed in launchpad-bazaar:
status: Confirmed → In Progress
Revision history for this message
Jonathan Lange (jml) wrote :

If this bug were any more closed, the UN would be imposing sanctions on it.

Changed in launchpad-bazaar:
status: In Progress → Fix Committed
Jonathan Lange (jml)
Changed in launchpad-bazaar:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.