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

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

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

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.

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.

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.

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.

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

(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.

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

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?

> 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

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: 01788 298152
36 Regent Street Fax: 01788 298159
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