qpush should suggest a target branch if the parent is hosted on Launchpad

[Ian Clatworthy]

Given a project hosted at lp:xxx and a local feature branch called yyy, qpush could suggest a sensible push location when one is yet to be defined, namely lp:~lp-user-id/xxx/yyy. I'm happy to add this at the Explorer layer but it would be generally useful for other qbzr-based UIs (like TortoiseBzr) so I'd prefer to see it at the qbzr layer.

See https://lists.launchpad.net/bzr-doc/msg00005.html for the bigger picture behind this suggestion.

[Alexander Belchenko (bialix)]

Ian Clatworthy пишет:
> Public bug reported:
>
> Given a project hosted at lp:xxx and a local feature branch called yyy,
> qpush could suggest a sensible push location when one is yet to be
> defined, namely lp:~lp-user-id/xxx/yyy. I'm happy to add this at the
> Explorer layer but it would be generally useful for other qbzr-based UIs
> (like TortoiseBzr) so I'd prefer to see it at the qbzr layer.

And how you see it can be done? How qbzr will know name of the project?
The launchpad user name available in bazaar.conf.

[Ian Clatworthy (ian-clatworthy)]

Alexander Belchenko wrote:
> Ian Clatworthy пишет:
>> Public bug reported:
>>
>> Given a project hosted at lp:xxx and a local feature branch called yyy,
>> qpush could suggest a sensible push location when one is yet to be
>> defined, namely lp:~lp-user-id/xxx/yyy. I'm happy to add this at the
>> Explorer layer but it would be generally useful for other qbzr-based UIs
>> (like TortoiseBzr) so I'd prefer to see it at the qbzr layer.
>
> And how you see it can be done? How qbzr will know name of the project?
> The launchpad user name available in bazaar.conf.
>

Taking an explorer feature branch as an example:

* parent branch is ../trunk/
* the parent branch of ../trunk/ is
  bzr+ssh://bazaar.launchpad.net/~bzr-explorer-dev/bzr-explorer/trunk/.

That pattern is highly predictable I believe. In general:

* if the parent branch is ../xxx AND
* it's parent is bzr+ssh://bazaar.launchpad.net/~owner/ppp/whatever/

then the project is ppp.

Ian C.

[Gary van der Merwe (garyvdm)]

On Tue, Nov 24, 2009 at 2:45 PM, Alexander Belchenko <email address hidden> wrote:
> And how you see it can be done? How qbzr will know name of the project?
> The launchpad user name available in bazaar.conf.

As Ian mentioned, from the parent. You probably need to recurse up the
parents, with a small max depth of say 4.

On Tue, Nov 24, 2009 at 2:31 PM, Ian Clatworthy
<email address hidden> wrote:
> I'm happy to add this at the
> Explorer layer but it would be generally useful for other qbzr-based UIs
> (like TortoiseBzr) so I'd prefer to see it at the qbzr layer.

I'm going to be a bit of a architecture astronaut here, and suggest
the this be added to the launchpad plugin, (which probably implies
also adding a api to bzrlib). This could be made accessible form the
command line by running bzr push :pushsuggest.

[Ian Clatworthy (ian-clatworthy)]

We could do something at the bzr or launchpad plugin level, yes. OTOH, the whole point of a suggestion is that the user can use the suggestion as a starting point for their preferred location. That's why I think doing it in the qbzr layer makes the most sense.

We could make it completely optional by only suggesting something if an option was given, e.g. bzr qpush --suggest. I'm ok with that though I'm not sure an option gains much over just putting a sensible suggestion in the editable combo box instead. It will only come into play IMO when it's appropriate. At other times, the field will remain empty as it is now.

[Alexander Belchenko (bialix)]

Ian Clatworthy пишет:
> We could do something at the bzr or launchpad plugin level, yes. OTOH,
> the whole point of a suggestion is that the user can use the suggestion
> as a starting point for their preferred location. That's why I think
> doing it in the qbzr layer makes the most sense.
>
> We could make it completely optional by only suggesting something if an
> option was given, e.g. bzr qpush --suggest. I'm ok with that though I'm
> not sure an option gains much over just putting a sensible suggestion in
> the editable combo box instead. It will only come into play IMO when
> it's appropriate. At other times, the field will remain empty as it is
> now.

It's not quite true: the field is empty but there is list with
suggestions (:parent, :submit locations in drop down list). We can add
another suggestion into the list.

But make it prominent and show suggested location will be "cool" effect,
I agree.

But suggestion implementation should be aware of difference between
local branches and light checkout from remote server. In the latter case
suggestions should be turned off -- we can't allow some code works
indefinitely, blocking main UI.

[Gary van der Merwe (garyvdm)]

Ian: I think you misunderstood me. I'm more than happy for the suggested location to be the default location in qpush for a branch that has no push location. I just would like the implementation of deciding what the suggested location is, for launchpad branches, to be in the launchpad plugin. This would make things flexible for other plugin authors to implement similar functionality for other hosting services.

I realize that doing things this way is much more work. So maybe we could hack a proff of concept together in qbzr, and refactor it later.

[Alexander Belchenko (bialix)]

Of course Launchpad is special case, but I think this approach could be more generic and extended
for many remote repo cases. I'll take a look.

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4636 (20091125) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru

[Ian Clatworthy (ian-clatworthy)]

Alexander Belchenko wrote:
> Of course Launchpad is special case, but I think this approach could be more generic and extended
> for many remote repo cases. I'll take a look.

Agreed. I did my best to isolate the LP specific code and only call it
at the last moment. It should be easy to extend it from here.

FWIW, Explorer now has a complementary feature called "Open in hosting
site" in the status bar. For LP, it effectively does 'lp-open' and then
some. Once again, I kept the design generic and isolated the LP specific
stuff so it should also be easy to extend that feature for other remote
sites.

Ian C.