Patchwork [01/12] gcc: Switch SRC_URI to use svn

login
register
mail settings
Submitter Khem Raj
Date Aug. 9, 2012, 1:25 a.m.
Message ID <1344475516-27640-1-git-send-email-raj.khem@gmail.com>
Download mbox | patch
Permalink /patch/34105/
State New
Headers show

Comments

Khem Raj - Aug. 9, 2012, 1:25 a.m.
svn tar balls are 96M as compared to 1.3G git tars
its unnessary to suck in that much of data.

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-devtools/gcc/gcc-4.7.inc |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
Koen Kooi - Aug. 10, 2012, 8:03 a.m.
Op 9 aug. 2012, om 03:25 heeft Khem Raj <raj.khem@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.

regards,

Koen
Paul Eggleton - Aug. 10, 2012, 8:47 a.m.
On Friday 10 August 2012 10:03:06 Koen Kooi wrote:
> Op 9 aug. 2012, om 03:25 heeft Khem Raj <raj.khem@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.

Cheers,
Paul
Phil Blundell - Aug. 10, 2012, 9:07 a.m.
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@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.  It's
not totally clear whether that situation is likely to arise again or
not.

In an ideal world I suppose the SVN web UI would expose some sort of API
that exported changesets in diff form, in which case you could write:

SRC_URI = "http://gcc.gnu.org/releases/gcc-4.7.1.tar.bz2 \
	http://gcc.gnu.org/svn/fetch?rev=189810"

or whatever for the patches that you wanted to backport.  But I don't
know of any way of doing that with the current viewvc.

p.
Koen Kooi - Aug. 10, 2012, 9:19 a.m.
Op 10 aug. 2012, om 10:47 heeft Paul Eggleton <paul.eggleton@linux.intel.com> het volgende geschreven:

> On Friday 10 August 2012 10:03:06 Koen Kooi wrote:
>> Op 9 aug. 2012, om 03:25 heeft Khem Raj <raj.khem@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.


I had similar problems as well when I worked for TI UK, it turned out to be proxy end point issues. After manually assigning an endpoint that was close by things improved a lot. The geo-ip based CDNs worked properly from then on. 
It might be that github suck in the UK, I only have one datapoint for the gcc stuff, which is my own connection at home. I only need to fetch gcc once, so I don't have a strong opinion on this switch, I just wanted to add some anecdotal evidence that the 1.3gb git download isn't all bad :)

regards,

Koen
Koen Kooi - Aug. 10, 2012, 9:22 a.m.
Op 10 aug. 2012, om 11:07 heeft Phil Blundell <philb@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@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.

regards,

Koen
Phil Blundell - Aug. 10, 2012, 9:30 a.m.
On Fri, 2012-08-10 at 11:22 +0200, Koen Kooi wrote:
> Op 10 aug. 2012, om 11:07 heeft Phil Blundell <philb@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@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.
Enrico Scholz - Aug. 10, 2012, 10:31 a.m.
Khem Raj <raj.khem-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> svn tar balls are 96M as compared to 1.3G git tars

perhaps it's time to implement support for shallow git repositories to
bitbake...


Enrico
Colin Walters - Aug. 10, 2012, 12:38 p.m.
On Fri, 2012-08-10 at 10:03 +0200, Koen Kooi wrote:
> Op 9 aug. 2012, om 03:25 heeft Khem Raj <raj.khem@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.

Couldn't OE do the initial git clone with --depth=1?
Martin Jansa - Aug. 10, 2012, 12:42 p.m.
On Fri, Aug 10, 2012 at 08:38:16AM -0400, Colin Walters wrote:
> On Fri, 2012-08-10 at 10:03 +0200, Koen Kooi wrote:
> > Op 9 aug. 2012, om 03:25 heeft Khem Raj <raj.khem@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.
> 
> Couldn't OE do the initial git clone with --depth=1?

That doesn't work very well when SRCREV is set to revision older then
HEAD^1.

Cheers,
Khem Raj - Aug. 10, 2012, 2:55 p.m.
-Khem

On Aug 10, 2012, at 2:07 AM, Phil Blundell <philb@gnu.org> wrote:

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


That's the plan when next release of gcc comes out
> 
> 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.  It's
> not totally clear whether that situation is likely to arise again or
> not.
> 
> In an ideal world I suppose the SVN web UI would expose some sort of API
> that exported changesets in diff form, in which case you could write:
> 
> SRC_URI = "http://gcc.gnu.org/releases/gcc-4.7.1.tar.bz2 \
>    http://gcc.gnu.org/svn/fetch?rev=189810"
> 
> or whatever for the patches that you wanted to backport.  But I don't
> know of any way of doing that with the current viewvc.
> 
> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Patch

diff --git a/meta/recipes-devtools/gcc/gcc-4.7.inc b/meta/recipes-devtools/gcc/gcc-4.7.inc
index 4ad4819..c6ba0b2 100644
--- a/meta/recipes-devtools/gcc/gcc-4.7.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.7.inc
@@ -1,6 +1,6 @@ 
 require gcc-common.inc
 
-PR = "r9"
+PR = "r10"
 
 # Third digit in PV should be incremented after a minor release
 # happens from this branch on gcc e.g. currently its 4.7.1
@@ -11,7 +11,7 @@  PR = "r9"
 # using 4.7.1.0 for upgrade path when we move past 4.7.2 release
 # then we should drop the last 0 as well.
 
-PV = "4.7.1.0+git${SRCPV}"
+PV = "4.7.1.0+svn${SRCPV}"
 
 # BINV should be incremented after updating to a revision
 # after a minor gcc release (e.g. 4.7.1 or 4.7.2) has been made
@@ -21,7 +21,7 @@  PV = "4.7.1.0+git${SRCPV}"
 
 BINV = "4.7.2"
 
-SRCREV = "d07e24f4ab59f264d68d21838795349faab5dede"
+SRCREV = "190218"
 BRANCH = "gcc-4_7-branch"
 FILESPATH = "${@base_set_filespath([ '${FILE_DIRNAME}/gcc-4.7' ], d)}"
 
@@ -36,7 +36,7 @@  LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \
                    file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1 \
 		   file://COPYING.RUNTIME;md5=fe60d87048567d4fe8c8a0ed2448bcc8"
 
-SRC_URI = "git://github.com/mirrors/gcc.git;branch=${BRANCH};protocol=git \
+SRC_URI = "svn://gcc.gnu.org/svn/gcc/branches;module=${BRANCH};protocol=http \
 	   file://gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch \
 	   file://100-uclibc-conf.patch \
            file://gcc-uclibc-locale-ctype_touplow_t.patch \
@@ -77,7 +77,7 @@  SRC_URI = "git://github.com/mirrors/gcc.git;branch=${BRANCH};protocol=git \
 	   file://disablesdt.patch \
 	  "
 
-S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/git"
+S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/${BRANCH}"
 B = "${WORKDIR}/${BRANCH}/build.${HOST_SYS}.${TARGET_SYS}"
 
 # Language Overrides