Re: Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2012-03-30 at 09:00 +0200, Martin Jansa wrote:
> On Thu, Mar 29, 2012 at 09:03:15PM -0400, Bruce Ashfield wrote:
> > On Thu, Mar 29, 2012 at 6:03 PM, Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> > >> - do the same thing for the linux-yocto kernel or add a --reference
> > >>   option to the git fetcher so that we can provide a local tree as a
> > >>   reference ?
> > >
> > > This is effectively how the repositories in DL_DIR are used. If you
> > > place a tree in the right place there, it should reuse references...
> > 
> > Agreed .. they definitely do here.
> 
> What's right place?
> 
> I guess the idea was to use --reference for e.g. some other kernel recipe
> sources checkout.
> 
> And I guess that building linux-foo won't notice that there is e.g.
> /OE/downloads/git2/gitorious.org.shr.linux.git:
> from which it can share a lot of objects using --reference
> 
> Bob Ham (rah on #oe) said that he is working on some sort of support
> for --reference with bitbake after I've refused to add just another
> linux-bar recipe to meta-smartphone, but not sure how he plans to
> implement it to be usefull and working oob in different env with
> different sources available in downloads dir.

You could conceivably symlink all your different kernel directories
together within git2/. As far as I can tell, the fetcher simply wouldn't
care in most cases. The branch structures could get a little mangled I
guess and you'd not want to share the resulting mirror tarballs.

There is an argument for using one large shared container for all the
git objects as another way of solving this. I don't know how well git
has that supported but at the object level its a non-issue at least.

Cheers,

Richard