Bad interaction between bzr+ssh://bazaar.launchpad.net/+branch/... URLs and branch stacking

[Max Bowsher]

There is a bad interaction between the new "resolve series devfocus branch aliases in the SSH server" code and branch stacking.

Bazaar is quite happy to let me do bzr push --stacked-on=bzr+ssh://bazaar.launchpad.net/+branch/qbzr lp:~me/qbzr/something - however, the branch scanner then reports it as an invalid stacking location.

Some component of Launchpad needs to resolve /+branch/ stacking locations to their full branch name or branch id.

As a suggestion, what if the branch scanner detected /+branch/ stacking locations, resolved them, and reset the .bzr/branch/branch.conf appropriately?

Ooooh..... idea. What if it was made possible for branches to be accessed via their Launchpad database id via http and bzr+ssh? - i.e. http://bazaar.launchpad.net/00/04/ee/09/ etc. *Then* you could have the branch scanner unconditionally rewrite the stacked_on_location to the id-based path, and the whole pain of stacking breaking when people rename branches goes away!

[Tim Penhey (thumper)]

Due to security concerns, we will never allow accessing a branch using their database id.

[Max Bowsher (maxb)]

Could you elaborate on why accessing a branch by database id is a security concern? I do not see what this exposes.

[Robert Collins (lifeless)]

On Tue, Nov 16, 2010 at 10:07 AM, Max Bowsher <email address hidden> wrote:
> Could you elaborate on why accessing a branch by database id is a
> security concern?  I do not see what this exposes.

Our security model depends on the path to the branch; accessing it *on
disk* by id requires a reverse lookup to figure out the user/project
and so on. Doable, not done.

[Max Bowsher (maxb)]

I see, that makes sense. In which case, providing a way to access branches via an immutable ID (be it primary key or some surrogate ID) sounds like an interesting possibility for fixing the "rename breaks stacking" issue without needing to run an O(number of stacked branches) job when a rename is performed.

[Jelmer Vernooij (jelmer)]

A similar situation like this happens is if there is a stacked-on location that uses lp.

This happens for example with https://code.launchpad.net/~dle-credativ/openobject-addons/test-6.0, which has a stacked-on location of lp:openobject-addons/6.0.

The branch scanner currently uses BranchSet().getByUniqueName to lookup the stacked-on branch location. Would it make sense for it to also try BranchSet().getByURL() ? That way lp: and bzr+ssh:// URLs should also be supported.

[Robert Collins (lifeless)]

Things have moved since the earlier comments; we now support a +branchid virtual path - and we do a double-lookup on it to get back to the real path. This is no worse than stacking on an lp url - however, we must not stack on an lp url as they are mutable.

I'm going to suggest that any solution to this which involves a different stacking url is going to simply replace the problem with a different one.

[Robert Collins (lifeless)]

(e.g. bzr shouldn't accept manual stack locations when pushing to LP branches). And LP's bzr server should not permit that.

[Dimitri John Ledkov (xnox)]

(about openobject-addons)
then all the branches which are not against trunk-addons are wasting ~130MB of space on launchpad. There are about 1300 branches against addons, let's hope half of them are against trunk addons (blessed addons), instead of uncertified/community extra addons. Which means that rough guestimate 70GB are wasted by openobject-addons.

The worst bit ofcourse is me uploading 130MB for one-liner commits on a dodgy 3G / small-isdn line.

Also any project that has activly developed / heavily diverged series is suffering from this.

For ubuntu project, branches *are* stacked onto series.
For lp projects, they are *not*.

I remember request to allow pushing to: lp:~/project/series/branch-nick to mimic ubuntu projects, not sure where the bug went now.

[Jelmer Vernooij (jelmer)]

On 09/11/11 19:58, Robert Collins wrote:
> (e.g. bzr shouldn't accept manual stack locations when pushing to LP
> branches). And LP's bzr server should not permit that.
>
Aren't we already intercepting writes to .bzr/control.conf? Could we
perhaps just accept stacked on URLs there and translate them to the
id-based stacking location?

Cheers,

Jelmer

[Robert Collins (lifeless)]

On Thu, Nov 10, 2011 at 8:19 AM, Dmitrijs Ledkovs
<email address hidden> wrote:
> (about openobject-addons)
> then all the branches which are not against trunk-addons are wasting ~130MB of space on launchpad. There are about 1300 branches against addons, let's hope half of them are against trunk addons (blessed addons), instead of uncertified/community extra addons. Which means that rough guestimate 70GB are wasted by openobject-addons.
>
> The worst bit ofcourse is me uploading 130MB for one-liner commits on a
> dodgy 3G / small-isdn line.
>
> Also any project that has activly developed / heavily diverged series is
> suffering  from this.

Is trunk-addons a fork, or a separate codebase?

[Robert Collins (lifeless)]

> Aren't we already intercepting writes to .bzr/control.conf? Could we
> perhaps just accept stacked on URLs there and translate them to the
> id-based stacking location?

Possibly - needs checking that bzr will not barf / overwrite or something.

-Rob

[Dimitri John Ledkov (ex-credativ) (dle-credativ)]

On 09/11/11 19:44, Robert Collins wrote:
> On Thu, Nov 10, 2011 at 8:19 AM, Dmitrijs Ledkovs
> <email address hidden> wrote:
>> (about openobject-addons)
>> then all the branches which are not against trunk-addons are wasting ~130MB of space on launchpad. There are about 1300 branches against addons, let's hope half of them are against trunk addons (blessed addons), instead of uncertified/community extra addons. Which means that rough guestimate 70GB are wasted by openobject-addons.
>>
>> The worst bit ofcourse is me uploading 130MB for one-liner commits on a
>> dodgy 3G / small-isdn line.
>>
>> Also any project that has activly developed / heavily diverged series is
>> suffering from this.
>
> Is trunk-addons a fork, or a separate codebase?
>

These have common history, and long histories after release (v5.0 is a
couple of years old and is still somewhat maintained, v6.0 released in
february and very actively maintained, v6.1 is "imminent" release)

$ bzr missing -d lp:openobject-addons/5.0 lp:openobject-addons
You have 328 extra revision(s)

$ bzr missing -d lp:openobject-addons/6.0 lp:openobject-addons
You have 347 extra revision(s)

$ bzr missing -d lp:openobject-addons/extra-trunk lp:openobject-addons
You have 1643 extra revision(s)
You are missing 5487 revision(s)

SET 1:
lp:opneobject-addons
lp:opneobject-addons/5.0
lp:opneobject-addons/6.0
- have common history

SET 2:
lp:opneobject-addons/extra-trunk
lp:opneobject-addons/extra-5.0
lp:opneobject-addons/extra-6.0
- have common history

But the two sets have no common history in between themselves.

(sometimes subdirs are "promoted" from SET-2 into SET-1 with `bzr rm' on
one branch, `cp' and `bzr add' on the other side)

As far as I know it used to be a one massive svn repository.

--
With best regards,

Dmitrijs Ledkovs

credativ ltd Tel: [phone]
36 Regent Street Fax: [phone]
Rugby CV21 2PS - UK http://www.credativ.co.uk

credativ Ltd is registered in England & Wales, company no. 5261743
Registered office: Nelson House, 2 Hamilton Terrace, Leamington Spa,
Warwickshire CV32 4LY

Certified by AccredIT UK with the ICT Supply standard of quality for
Software Product Design and Development