[OE-core] [PATCH 01/12] gcc: Switch SRC_URI to use svn

[Phil Blundell]

On Fri, 2012-08-10 at 11:22 +0200, Koen Kooi wrote:
> Op 10 aug. 2012, om 11:07 heeft Phil Blundell <philb at gnu.org> het volgende geschreven:
> 
> > On Fri, 2012-08-10 at 09:47 +0100, Paul Eggleton wrote:
> >> On Friday 10 August 2012 10:03:06 Koen Kooi wrote:
> >>> Op 9 aug. 2012, om 03:25 heeft Khem Raj <raj.khem at gmail.com> het volgende 
> >> geschreven:
> >>>> svn tar balls are 96M as compared to 1.3G git tars
> >>>> its unnessary to suck in that much of data.
> >>> 
> >>> That's indeed a big difference and also expected, with svn you only get
> >>> revision N and N-1, with git you get everything. But even so, I can fetch
> >>> that 1.3GB a *lot* faster than that 0.1GB svn. Maybe I'm on the wrong side
> >>> of the ocean, but that gcc svn server is sloooooooooooooooooooooow.
> >> 
> >> FWIW the git option was much, much, much slower for us here in the UK.
> > 
> > Maybe we should just go back to using the released tarballs for gcc
> > rather than any sort of SCM checkout.  That would be an 80MB download
> > for the tar.bz2 and of course you can get it from your local mirror.
> > 
> > I think the original reason we switched to using the SCM checkout was
> > that, at the time, we were carrying around a huge number of backported
> > patches that hadn't quite made it into any released version yet.
> 
> We pointed it at the release branch, so updating from x.y.0 to x.y.4 was just a srcrev change. But the same can be done by exporting the patches with git-format-patch and importing them into the OE tree.

Right.  Or, once x.y.4 actually gets released, it would be available as
a tarball in its own right anyway.  The only time when it's at all
tricky is the period just before that happens, when there are
potentially-important fixes in the gcc-x.y branch that aren't yet in any
released version.  But, as you say, we can just import those as patches
and I think/hope their number should be fairly limited.

p.