eglibc: use HTTP for svn checkout

Submitted by Ryan D Phillips on Dec. 13, 2010, 5:13 p.m.

Details

Message ID 4D065431.6080304@dell.com
State Under Review, archived
Headers show

Commit Message

Ryan D Phillips Dec. 13, 2010, 5:13 p.m.
SVN over HTTP is a more reliable transport for developers behind 
restrictive
proxies.

Regards,
Ryan
From c0a5ad76e64d961735b5c07326d86107ef98f6a1 Mon Sep 17 00:00:00 2001
From: Ryan D Phillips <ryan_d_phillips@dell.com>
Date: Mon, 13 Dec 2010 10:00:27 -0600
Subject: [PATCH] eglibc: Use HTTP for svn checkout

SVN over HTTP is a more reliable transport for developers behind restrictive
proxies.

Signed-off-by: Ryan D Phillips <ryan_d_phillips@dell.com>
---
 recipes/eglibc/eglibc_2.10.bb |    2 +-
 recipes/eglibc/eglibc_2.11.bb |    2 +-
 recipes/eglibc/eglibc_2.12.bb |    2 +-
 recipes/eglibc/eglibc_2.9.bb  |    2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

Patch hide | download patch | download mbox

diff --git a/recipes/eglibc/eglibc_2.10.bb b/recipes/eglibc/eglibc_2.10.bb
index 1eab7eb..e873bea 100644
--- a/recipes/eglibc/eglibc_2.10.bb
+++ b/recipes/eglibc/eglibc_2.10.bb
@@ -7,7 +7,7 @@  PR = "${INC_PR}.10"
 PR_append = "+svnr${SRCPV}"
 SRCREV="10152"
 EGLIBC_BRANCH="eglibc-2_10"
-SRC_URI = "svn://svn.eglibc.org/branches;module=${EGLIBC_BRANCH};proto=svn \
+SRC_URI = "svn://svn.eglibc.org/svn/branches;module=${EGLIBC_BRANCH};proto=http \
            file://eglibc-svn-arm-lowlevellock-include-tls.patch \
            file://armv4t-interworking.patch \
            file://IO-acquire-lock-fix.patch \
diff --git a/recipes/eglibc/eglibc_2.11.bb b/recipes/eglibc/eglibc_2.11.bb
index b249f29..4a6f25d 100644
--- a/recipes/eglibc/eglibc_2.11.bb
+++ b/recipes/eglibc/eglibc_2.11.bb
@@ -8,7 +8,7 @@  PR = "${INC_PR}.8"
 PR_append = "+svnr${SRCPV}"
 SRCREV="12231"
 EGLIBC_BRANCH="eglibc-2_11"
-SRC_URI = "svn://svn.eglibc.org/branches;module=${EGLIBC_BRANCH};proto=svn \
+SRC_URI = "svn://svn.eglibc.org/svn/branches;module=${EGLIBC_BRANCH};proto=http \
            file://eglibc-svn-arm-lowlevellock-include-tls.patch \
            file://IO-acquire-lock-fix.patch \
            file://shorten-build-commands.patch \
diff --git a/recipes/eglibc/eglibc_2.12.bb b/recipes/eglibc/eglibc_2.12.bb
index 1285568..214da69 100644
--- a/recipes/eglibc/eglibc_2.12.bb
+++ b/recipes/eglibc/eglibc_2.12.bb
@@ -8,7 +8,7 @@  PR = "${INC_PR}.7"
 PR_append = "+svnr${SRCPV}"
 SRCREV="12230"
 EGLIBC_BRANCH="eglibc-2_12"
-SRC_URI = "svn://svn.eglibc.org/branches;module=${EGLIBC_BRANCH};proto=svn \
+SRC_URI = "svn://svn.eglibc.org/svn/branches;module=${EGLIBC_BRANCH};proto=http \
            file://eglibc-svn-arm-lowlevellock-include-tls.patch \
            file://IO-acquire-lock-fix.patch \
            file://shorten-build-commands.patch \
diff --git a/recipes/eglibc/eglibc_2.9.bb b/recipes/eglibc/eglibc_2.9.bb
index c06345e..b096469 100644
--- a/recipes/eglibc/eglibc_2.9.bb
+++ b/recipes/eglibc/eglibc_2.9.bb
@@ -7,7 +7,7 @@  PR = "${INC_PR}.10"
 PR_append = "+svnr${SRCPV}"
 SRCREV="10153"
 EGLIBC_BRANCH="eglibc-2_9"
-SRC_URI = "svn://svn.eglibc.org/branches;module=${EGLIBC_BRANCH};proto=svn \
+SRC_URI = "svn://svn.eglibc.org/svn/branches;module=${EGLIBC_BRANCH};proto=http \
            file://eglibc-svn-arm-lowlevellock-include-tls.patch \
            file://armv4t-interworking.patch \
            file://IO-acquire-lock-fix.patch \

Comments

Khem Raj Dec. 13, 2010, 8 p.m.
On Mon, Dec 13, 2010 at 9:13 AM, Ryan D Phillips
<ryan_d_phillips@dell.com> wrote:
>  SVN over HTTP is a more reliable transport for developers behind
> restrictive
> proxies.
>

and how much slower/faster is it when compared to svn protocol ?


> Regards,
> Ryan
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>
Aeschbacher, Fabrice Dec. 14, 2010, 7:57 a.m.
Agreed; this is a change I have to do manually every time

Regards,
  Fabrice

-----Ursprüngliche Nachricht-----
Von: openembedded-devel-bounces@lists.openembedded.org [mailto:openembedded-devel-bounces@lists.openembedded.org] Im Auftrag von Ryan D Phillips
Gesendet: Montag, 13. Dezember 2010 18:13
An: openembedded-devel@lists.openembedded.org
Betreff: [oe] [PATCH] eglibc: use HTTP for svn checkout

  SVN over HTTP is a more reliable transport for developers behind 
restrictive
proxies.

Regards,
Ryan
Ryan D Phillips Dec. 14, 2010, 4:30 p.m.
On 12/13/2010 2:00 PM, Khem Raj wrote:
> On Mon, Dec 13, 2010 at 9:13 AM, Ryan D Phillips
> <ryan_d_phillips@dell.com>  wrote:
>>   SVN over HTTP is a more reliable transport for developers behind
>> restrictive
>> proxies.
>>
>
> and how much slower/faster is it when compared to svn protocol ?
>

The speed depends on which subversion client backend someone is using. 
HTTP will be slower than using the svn native protocol, but the serf 
subversion backend will perform parallel fetches.

I would like to see this patch get into the OE tree to make the tree 
more robust to proxies. Currently, this is the only customization I need 
for the projects I work on.

Regards,
Ryan Phillips
Tom Rini Dec. 14, 2010, 4:55 p.m.
On 12/14/2010 09:30 AM, Ryan D Phillips wrote:
> On 12/13/2010 2:00 PM, Khem Raj wrote:
>> On Mon, Dec 13, 2010 at 9:13 AM, Ryan D Phillips
>> <ryan_d_phillips@dell.com> wrote:
>>> SVN over HTTP is a more reliable transport for developers behind
>>> restrictive
>>> proxies.
>>>
>>
>> and how much slower/faster is it when compared to svn protocol ?
>>
>
> The speed depends on which subversion client backend someone is using.
> HTTP will be slower than using the svn native protocol, but the serf
> subversion backend will perform parallel fetches.
>
> I would like to see this patch get into the OE tree to make the tree
> more robust to proxies. Currently, this is the only customization I need
> for the projects I work on.

Note that if you use a mirror site with the SVN checkout archive in it, 
you won't try and do the fetch at all.  This may or may not be 
applicable to your case.  For your case I think what we really want is a 
way to globally toggle the svn protocol argument.
Khem Raj Dec. 14, 2010, 5:09 p.m.
On Tue, Dec 14, 2010 at 8:30 AM, Ryan D Phillips
<ryan_d_phillips@dell.com> wrote:
> On 12/13/2010 2:00 PM, Khem Raj wrote:
>>
>> On Mon, Dec 13, 2010 at 9:13 AM, Ryan D Phillips
>> <ryan_d_phillips@dell.com>  wrote:
>>>
>>>  SVN over HTTP is a more reliable transport for developers behind
>>> restrictive
>>> proxies.
>>>
>>
>> and how much slower/faster is it when compared to svn protocol ?
>>
>
> The speed depends on which subversion client backend someone is using. HTTP
> will be slower than using the svn native protocol, but the serf subversion
> backend will perform parallel fetches.
>
> I would like to see this patch get into the OE tree to make the tree more
> robust to proxies. Currently, this is the only customization I need for the
> projects I work on.

Yes your pie :) but this is not the only problem I guess in OE with
regard to fetching behind the proxies.
you can also use a appending mechanism in your layer and make this
change without changing OE at all


>
> Regards,
> Ryan Phillips
>
Khem Raj Dec. 14, 2010, 5:11 p.m.
On Tue, Dec 14, 2010 at 8:55 AM, Tom Rini <tom_rini@mentor.com> wrote:
> On 12/14/2010 09:30 AM, Ryan D Phillips wrote:
>>
>> On 12/13/2010 2:00 PM, Khem Raj wrote:
>>>
>>> On Mon, Dec 13, 2010 at 9:13 AM, Ryan D Phillips
>>> <ryan_d_phillips@dell.com> wrote:
>>>>
>>>> SVN over HTTP is a more reliable transport for developers behind
>>>> restrictive
>>>> proxies.
>>>>
>>>
>>> and how much slower/faster is it when compared to svn protocol ?
>>>
>>
>> The speed depends on which subversion client backend someone is using.
>> HTTP will be slower than using the svn native protocol, but the serf
>> subversion backend will perform parallel fetches.
>>
>> I would like to see this patch get into the OE tree to make the tree
>> more robust to proxies. Currently, this is the only customization I need
>> for the projects I work on.
>
> Note that if you use a mirror site with the SVN checkout archive in it, you
> won't try and do the fetch at all.  This may or may not be applicable to
> your case.  For your case I think what we really want is a way to globally
> toggle the svn protocol argument.

yes that would be something more useful. I guess we could add it to
all SCM fetching recipes.

>
> --
> Tom Rini
> Mentor Graphics Corporation
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
Enrico Scholz Dec. 15, 2010, 10:32 a.m.
Ryan D Phillips <ryan_d_phillips@dell.com> writes:

> I would like to see this patch get into the OE tree to make the tree
> more robust to proxies. Currently, this is the only customization I
> need for the projects I work on.

fwiw, I wrote a local patch for bitbake

          https://www.cvg.de/people/ensc/0004-svn-tunnel.patch

which allows fetching of svn:// uris through an http proxy (which must
be configured to allow CONNECTs to svn servers).  I thought it would be
some local hack but when there is wider interest I will submit it to the
bitbake ml.


Enrico
Chris Larson Dec. 15, 2010, 4:35 p.m.
On Tue, Dec 14, 2010 at 10:11 AM, Khem Raj <raj.khem@gmail.com> wrote:
>> Note that if you use a mirror site with the SVN checkout archive in it, you
>> won't try and do the fetch at all.  This may or may not be applicable to
>> your case.  For your case I think what we really want is a way to globally
>> toggle the svn protocol argument.
>
> yes that would be something more useful. I guess we could add it to
> all SCM fetching recipes.

I wonder if the PREMIRRORS/MIRRORS handling is smart enough to let us
use its regex for the components to replace protocol= in the url
parameters.
Andreas Oberritter Dec. 15, 2010, 4:43 p.m.
On 12/15/2010 05:35 PM, Chris Larson wrote:
> On Tue, Dec 14, 2010 at 10:11 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>> Note that if you use a mirror site with the SVN checkout archive in it, you
>>> won't try and do the fetch at all.  This may or may not be applicable to
>>> your case.  For your case I think what we really want is a way to globally
>>> toggle the svn protocol argument.
>>
>> yes that would be something more useful. I guess we could add it to
>> all SCM fetching recipes.
> 
> I wonder if the PREMIRRORS/MIRRORS handling is smart enough to let us
> use its regex for the components to replace protocol= in the url
> parameters.

This won't suffice, because svn may have different URLs for svn and
http, like in the discussed patch (branches vs. svn/branches):

-SRC_URI =
"svn://svn.eglibc.org/branches;module=${EGLIBC_BRANCH};proto=svn \
+SRC_URI =
"svn://svn.eglibc.org/svn/branches;module=${EGLIBC_BRANCH};proto=http \

Regards,
Andreas
Chris Larson Dec. 15, 2010, 4:45 p.m.
On Wed, Dec 15, 2010 at 9:43 AM, Andreas Oberritter
<obi@opendreambox.org> wrote:
> On 12/15/2010 05:35 PM, Chris Larson wrote:
>> On Tue, Dec 14, 2010 at 10:11 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>>> Note that if you use a mirror site with the SVN checkout archive in it, you
>>>> won't try and do the fetch at all.  This may or may not be applicable to
>>>> your case.  For your case I think what we really want is a way to globally
>>>> toggle the svn protocol argument.
>>>
>>> yes that would be something more useful. I guess we could add it to
>>> all SCM fetching recipes.
>>
>> I wonder if the PREMIRRORS/MIRRORS handling is smart enough to let us
>> use its regex for the components to replace protocol= in the url
>> parameters.
>
> This won't suffice, because svn may have different URLs for svn and
> http, like in the discussed patch (branches vs. svn/branches):
>
> -SRC_URI =
> "svn://svn.eglibc.org/branches;module=${EGLIBC_BRANCH};proto=svn
>
> \
> +SRC_URI =
> "svn://svn.eglibc.org/svn/branches;module=${EGLIBC_BRANCH};proto=http
>
> \

And of course, changes to the url can also be done via PREMIRRORS.
You'd just have the first one a specific entry to redirect eglibc, and
the second a fallback for non-specific.  Of course, there's nothing
wrong with using bbappend/amend.inc for this, just another
possibility.