should stack foreign branch imports

[Jelmer Vernooij]

Launchpad code imports from bzr-git/bzr-svn/bzr-hg use deterministic revision ids so would benefit from stacking just like mirrors of bzr branches. This should just be a matter of adding the right fallback repositories.

[Jonathan Lange (jml)]

Are you sure we don't at the moment? Can you please point me to a URL?

[Jelmer Vernooij (jelmer)]

I couldn't find any code that actually adds any fallback repositories, but I'll see if I can demonstrate this as well using gnome-specimen.

[Michael Hudson-Doyle (mwhudson)]

I'm pretty sure we don't do this on the codehost, but it would also be good to use the trunk import as a basis for the import of a sibling branch, and I'm absolutely certain that we don't do that (and also that I don't really know *how* to do that...).

[Jelmer Vernooij (jelmer)]

Is there any reason not to treat code imports done using the foreign branch plugins more like the mirrors of "native" Bazaar branches?

[Jonathan Lange (jml)]

On Sun, Nov 22, 2009 at 11:38 AM, Jelmer Vernooij <email address hidden> wrote:
> Is there any reason not to treat code imports done using the foreign
> branch plugins more like the mirrors of "native" Bazaar branches?
>

We've long thought it should be the other way around.

Much of the code import system is built around the premise that
importing a branch can be computationally expensive. Mirroring a
branch is rarely so.

jml

[Michael Hudson-Doyle (mwhudson)]

Jonathan Lange wrote:
> On Sun, Nov 22, 2009 at 11:38 AM, Jelmer Vernooij <email address hidden> wrote:
>> Is there any reason not to treat code imports done using the foreign
>> branch plugins more like the mirrors of "native" Bazaar branches?
>>
>
> We've long thought it should be the other way around.

I'd definitely go as far as to say that it's silly that the two systems
share so little code...

> Much of the code import system is built around the premise that
> importing a branch can be computationally expensive. Mirroring a
> branch is rarely so.

Well, that's the theory, mirroring branches certainly can be expensive,
like the killer mysql branch and the sundry problems we've had with open
office branches...

Cheers,
mwh

[Michael Hudson-Doyle (mwhudson)]

So here's one approach to fixing this:

When processing an import branch X, if the default stacked on branch for branch X's target is also an import branch of the same type, arrange to pass the id of the default stacked on branch to the worker that processes branch X.

When a worker is passed a branch id to stack on, when it creates/clones the local branch to work into, it stacks it on the designated branch in the central store.

When the import is done, the worker should ensure that the branch in the central is also stacked (using a relative path!) on the stacked-on-branch in the central store, and the puller should also stack the branch on the central store.

None of this sounds too terribly difficult, which is good.

[Jelmer Vernooij (jelmer)]

This won't allow stacking on non-imported branches, which might be more common in the future (especially with code imports of bzr branches, and round tripping).

Do we have access to the (public) development focus branches from the code importds?

[Michael Hudson-Doyle (mwhudson)]

I imagine that http://bazaar.launchpad.net/... urls work from the importds.

The right fix is still some kind of token that allows write access to one branch and read access to some number of other branches...

[Jelmer Vernooij (jelmer)]

On 08/30/2011 12:26 AM, Michael Hudson-Doyle wrote:
> I imagine that http://bazaar.launchpad.net/... urls work from the
> importds.
>
> The right fix is still some kind of token that allows write access to
> one branch and read access to some number of other branches...
>
If we start by passing http://bazaar.launchpad.net/ URLs around and just
supporting public stacked-on branches, then we could later add a
token-based system and simply embed the tokens in the URLs as we're
already doing for various other things (build logs, private PPA's).

Cheers,

Jelmer

[Jelmer Vernooij (jelmer)]

Since Michael is working on letting branches be accessed using tokens, I'm going to wait on that.

[Robert Collins (lifeless)]

On Sat, Sep 24, 2011 at 5:57 AM, Jelmer Vernooij
<email address hidden> wrote:
> Since Michael is working on letting branches be accessed using tokens,
> I'm going to wait on that.

Michael and I discussed things and the token idea isn't a flyer at this point.

If the importd's need access to a private branch, they should login.
Likewise buildds - yes there are some logistics there, like resetting
their credentials on each build, but we don't need a new concept to
support this well.

Note that an importd stacking on a private branch is a truely terrible
idea unless the import branch is itself private - and thats much more
involved than merely getting access to the stacked-on branch. (we have
to privatise the entire thing end to end or someone can merely grab
the url and convert the source themselves.

[Launchpad QA Bot (lpqabot)]

Fixed in stable r14141 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/14141>.

[Jelmer Vernooij (jelmer)]

This breaks bzr-git imports; I'm looking at a fix.

[William Grant (wgrant)]

Reverted in r14154.

[Launchpad QA Bot (lpqabot)]

Fixed in stable r14243 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/14243>.

[Jelmer Vernooij (jelmer)]

There is yet another bzr-git<->bzr compatibility issue that has crept up. I'm putting up a patch and am looking into improving the bzr-git testsuite.

[Launchpad QA Bot (lpqabot)]

Fixed in stable r14253 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/14253>.