Patchwork eglibc: use HTTP for svn checkout

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(-)

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

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

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

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.

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
>

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
>

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

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.

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

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.