Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

Daniel Shahaf-5
Thorsten Schöning wrote on Sun, Nov 04, 2018 at 16:42:11 +0100:
> Guten Tag Thorsten Schöning,
> am Sonntag, 4. November 2018 um 16:05 schrieben Sie:
>
> >> The server at '[...]' does not support the HTTP/DAV protocol.
>
> Others have the same problem and while it is true that GitHub might
> have implemented something on their own, it might help to have a look
> at the changes between 1.10 and 1.11 regarding the protocol.

That took exactly two minutes to grep, diff, and blame.

See https://svn.apache.org/r1825302.  1.11 has new behaviour whereby it
deliberately errors out if the HTTP response does not include a "DAV:"
header, apparently in to improve the failure mode on URLs that are not
Subversion repository URLs.

> I've already written to the GitHub support but nobody seemed to care yet.

Well, we can't fix this issue on our end.  Our client code works with
our server code, but there is no way for us to ensure that our client
code (continues to) work with third-party server reimplementations.
That said, if any GitHub staff are reading this, you're welcome to
contact us on the dev@ list and we'll see what we can do.

Cheers,

Daniel
(We can't just "remove the new check" because that would regress the
failure mode that check was added to improve.)
Reply | Threaded
Open this post in threaded view
|

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

Branko Čibej
On 04.11.2018 16:05, Thorsten Schöning wrote:

> Hi all,
>
> GitHub documents to support Subversion clients and I'm using that for
> many projects to include them in one of my working copies using
> svn:externals. Since upgrading TortoiseSVN from 1.10 to 1.11 I get the
> following error for all of those projects:
>
>> The server at '[...]' does not support the HTTP/DAV protocol.
> This happens to a long list of projects, some examples:
>
>> https://github.com/apache/commons-lang.git/tags/LANG_3_6
>> https://github.com/pgjdbc/pgjdbc.git/tags/REL42.2.2
>> https://github.com/ams-tschoening/kaitai_struct_tests.git/branches/libs_java_3rd_usage
The first two URLs return a 404. The third returns 410 and says "feature
gone" ... I think you'll need better examples.


> I've asked about that problem on SO[1], which revealed that the switch
> from 1.10 to 1.11 really is the problem. Downgrading resolves the
> problem.
>
> Do you have any idea what could be the root cause? Is there something
> that needs to be configured specially?

The root cause is that GitHub does not implement Subversion's HTTP/DAV
protocol correctly.

In 1.11, the Subversion client has become stricter about the server
requirements (see: https://svn.apache.org/r1825302). Specifically, we
require that the server sends DAV response headers to the OPTIONS
request, which we use for capability negotiation. Here's an example of a
correct response:

HTTP/1.1 200 OK
Date: Sun, 04 Nov 2018 15:40:24 GMT
Server: Apache/2.4.7 (Ubuntu)
DAV: 1,2
DAV: version-control,checkout,working-resource
DAV: merge,baseline,activity,version-controlled-collection
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
...


The GitHub server does not return any DAV: header for the OPTIONS
request, so the response is considered incorrect. I suggest sending a
bug report to GitHub; the attached script can be used to simulate
Subversion's OPTIONS request.

In the meantime, staying with 1.10.x appears to be the only option if
you have to use GitHub's SVN protocol.

-- Brane


svnoptions.sh.txt (866 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

Branko Čibej
In reply to this post by Daniel Shahaf-5
On 04.11.2018 17:06, Thorsten Schöning wrote:

> Guten Tag Thorsten Schöning,
> am Sonntag, 4. November 2018 um 16:42 schrieben Sie:
>
>> Others have the same problem and while it is true that GitHub might
>> have implemented something on their own, it might help to have a look
>> at the changes between 1.10 and 1.11 regarding the protocol.
> Guess I found it:
>
>>    * Better error when http:// URL is not a Subversion repository (r1825302)
>>       /* Bail out early if we're not talking to a DAV server.
>>          Note that this check is only valid if we've received a success
>>          response; redirects and errors don't count. */
>>       if (opt_ctx->handler->sline.code >= 200
>>           && opt_ctx->handler->sline.code < 300
>>           && !opt_ctx->received_dav_header)
>>         {
>>           return svn_error_createf
>>             (SVN_ERR_RA_DAV_OPTIONS_REQ_FAILED, NULL,
>>              _("The server at '%s' does not support the HTTP/DAV protocol"),
>>              session->session_url_str);
>>         }
> "received_dav_header" is only set at one place, isn't that check
> wrong? The code handles more than only DAV successfully from my point
> of view:


I'm not sure what you mean by "handles more than only DAV successfully"
... this code only checks if we received any DAV: header in the response
to the OPTIONS request, no more and no less. HTTP/DAV and Subversion's
HTTP protocol use that for capability negotiation at the start of a session.

And yes, the HTTP/DAV specification requires that header to be present
in the response.

-- Brane

Reply | Threaded
Open this post in threaded view
|

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

Branko Čibej
On 04.11.2018 17:47, Branko Čibej wrote:

> On 04.11.2018 17:06, Thorsten Schöning wrote:
>> Guten Tag Thorsten Schöning,
>> am Sonntag, 4. November 2018 um 16:42 schrieben Sie:
>>
>>> Others have the same problem and while it is true that GitHub might
>>> have implemented something on their own, it might help to have a look
>>> at the changes between 1.10 and 1.11 regarding the protocol.
>> Guess I found it:
>>
>>>    * Better error when http:// URL is not a Subversion repository (r1825302)
>>>       /* Bail out early if we're not talking to a DAV server.
>>>          Note that this check is only valid if we've received a success
>>>          response; redirects and errors don't count. */
>>>       if (opt_ctx->handler->sline.code >= 200
>>>           && opt_ctx->handler->sline.code < 300
>>>           && !opt_ctx->received_dav_header)
>>>         {
>>>           return svn_error_createf
>>>             (SVN_ERR_RA_DAV_OPTIONS_REQ_FAILED, NULL,
>>>              _("The server at '%s' does not support the HTTP/DAV protocol"),
>>>              session->session_url_str);
>>>         }
>> "received_dav_header" is only set at one place, isn't that check
>> wrong? The code handles more than only DAV successfully from my point
>> of view:
>
> I'm not sure what you mean by "handles more than only DAV successfully"
> ... this code only checks if we received any DAV: header in the response
> to the OPTIONS request, no more and no less. HTTP/DAV and Subversion's
> HTTP protocol use that for capability negotiation at the start of a session.
>
> And yes, the HTTP/DAV specification requires that header to be present
> in the response.

FWIW, the fix could be as simple as GitHub's server returning something like

    DAV: http://github.com/fake-svn-server


in their response headers ...

-- Brane

Reply | Threaded
Open this post in threaded view
|

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

Branko Čibej
In reply to this post by Branko Čibej
On 04.11.2018 17:41, Branko Čibej wrote:

> On 04.11.2018 16:05, Thorsten Schöning wrote:
>> Hi all,
>>
>> GitHub documents to support Subversion clients and I'm using that for
>> many projects to include them in one of my working copies using
>> svn:externals. Since upgrading TortoiseSVN from 1.10 to 1.11 I get the
>> following error for all of those projects:
>>
>>> The server at '[...]' does not support the HTTP/DAV protocol.
>> This happens to a long list of projects, some examples:
>>
>>> https://github.com/apache/commons-lang.git/tags/LANG_3_6
>>> https://github.com/pgjdbc/pgjdbc.git/tags/REL42.2.2
>>> https://github.com/ams-tschoening/kaitai_struct_tests.git/branches/libs_java_3rd_usage
> The first two URLs return a 404. The third returns 410 and says "feature
> gone" ... I think you'll need better examples.

Sorry, that's incorrect, I wrote that before I fixed my svnoptions.sh
script. Please ignore.

Reply | Threaded
Open this post in threaded view
|

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

Nico Kadel-Garcia-2
In reply to this post by Daniel Shahaf-5
On Sun, Nov 4, 2018 at 10:05 AM Thorsten Schöning <[hidden email]> wrote:

>
> Hi all,
>
> GitHub documents to support Subversion clients and I'm using that for
> many projects to include them in one of my working copies using
> svn:externals. Since upgrading TortoiseSVN from 1.10 to 1.11 I get the
> following error for all of those projects:
>
> > The server at '[...]' does not support the HTTP/DAV protocol.
>
> This happens to a long list of projects, some examples:
>
> > https://github.com/apache/commons-lang.git/tags/LANG_3_6
> > https://github.com/pgjdbc/pgjdbc.git/tags/REL42.2.2
> > https://github.com/ams-tschoening/kaitai_struct_tests.git/branches/libs_java_3rd_usage

Can you switch to using TortoiseGit locally, and avoid the extra
compatibility layers? It would take decisions about your workflow to
do this, but I've found its built-in git-svn toolkit to be effective
and robust for upstream Subversion repositories even where I needed to
retain contact with upstream Subversion repositories..

> I've asked about that problem on SO[1], which revealed that the switch
> from 1.10 to 1.11 really is the problem. Downgrading resolves the
> problem.
>
> Do you have any idea what could be the root cause? Is there something
> that needs to be configured specially?
>
> Thanks!
>
> [1]: https://stackoverflow.com/a/53132753/2055163
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
> --
> Thorsten Schöning       E-Mail: [hidden email]
> AM-SoFT IT-Systeme      http://www.AM-SoFT.de/
>
> Telefon...........05151-  9468- 55
> Fax...............05151-  9468- 88
> Mobil..............0178-8 9468- 04
>
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>
Reply | Threaded
Open this post in threaded view
|

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

Branko Čibej
In reply to this post by Branko Čibej
On 04.11.2018 18:57, Thorsten Schöning wrote:

> Guten Tag Branko Čibej,
> am Sonntag, 4. November 2018 um 17:47 schrieben Sie:
>
>> I'm not sure what you mean by "handles more than only DAV successfully"
> I thought it might be possible that GitHub answers differently but
> properly, because the other check mentioned something about HTTP v2.
> Because of TLS, I was unable to look at the requests and responses
> then, but it's like you said, they don't provide DAV-headers in their
> response to OPTION.
>
>> And yes, the HTTP/DAV specification requires that header to be present
>> in the response.
> Which you didn't care about before and things worked for some years
> for some users.

We made this change because users complained about unhelpful error
messages when they tried to connect to a server that did not even
implement HTTP/DAV. The error message was "Malformed XML in response"
which wasn't exactly helpful for diagnosing the problem.

I admit I didn't have GitHub in mind when I added this check. ...


> Now "we" need to get GitHub to change their
> implementation and I didn't even get an automatic bot-reply to my
> question on Friday yet. :-) Lets see how things are going after I send
> them this thread...

I keep wondering why the GitHub staff didn't contact us when they
implemented their SVN-like server. This might all have been avoided if
they had. We already spent time trying to work around GitHub's faulty
implementation (q.v. r1707164), but there's a limit to how much we can
or should do. The protocols in question are quite well documented after
all, both in RFCs and in our own notes.


-- Brane

Reply | Threaded
Open this post in threaded view
|

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

Daniel Shahaf-2
In reply to this post by Branko Čibej
Thorsten Schöning wrote on Sun, 04 Nov 2018 18:57 +0100:
> Guten Tag Branko Čibej,
> am Sonntag, 4. November 2018 um 17:47 schrieben Sie:
>
> > I'm not sure what you mean by "handles more than only DAV successfully"
>
> I thought it might be possible that GitHub answers differently but
> properly, because the other check mentioned something about HTTP v2.

The terminology is a bit unfortunate here.

There's a HTTP/2 protocol, rfc7540, but it has *nothing* to do with what
Subversion design documents refer to as "HTTPv2".  The latter is simply
a different way for libsvn_ra_serf to communicate with mod_dav_svn, but
it was designed and implemented in terms of HTTP/1 requests and responses.
(Of course, one ought to be able to run HTTPv2 over HTTP/2 if one uses
serf and httpd versions that support the latter.)

In hindsight, we should have chosen a different name for that protocol revision.
Reply | Threaded
Open this post in threaded view
|

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

Ryan Schmidt-10
In reply to this post by Branko Čibej


On Nov 4, 2018, at 11:57, Thorsten Schöning wrote:

> Now "we" need to get GitHub to change their
> implementation and I didn't even get an automatic bot-reply to my
> question on Friday yet. :-) Lets see how things are going after I send
> them this thread...

I'd be interested to know the resolution, since I use the GitHub svn bridge daily. I'll hold off on upgrading past Subversion 1.10.x for now but could you keep us informed about what GitHub does to solve this?


Wasn't there going to be support in the Subversion client for dealing with git repositories directly? Is that still in the works?


Reply | Threaded
Open this post in threaded view
|

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

Branko Čibej
On 05.11.2018 04:45, Ryan Schmidt wrote:

>
> On Nov 4, 2018, at 11:57, Thorsten Schöning wrote:
>
>> Now "we" need to get GitHub to change their
>> implementation and I didn't even get an automatic bot-reply to my
>> question on Friday yet. :-) Lets see how things are going after I send
>> them this thread...
> I'd be interested to know the resolution, since I use the GitHub svn bridge daily. I'll hold off on upgrading past Subversion 1.10.x for now but could you keep us informed about what GitHub does to solve this?
>
>
> Wasn't there going to be support in the Subversion client for dealing with git repositories directly? Is that still in the works?


There's a branch that has very rudimentary support for read-only
checkouts from Git repositories. It hasn't been updated in a while. If
anyone would like to help with that, please do join us on our dev@ list.

-- Brane

Reply | Threaded
Open this post in threaded view
|

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

Nico Kadel-Garcia-2
In reply to this post by Ryan Schmidt-10
On Mon, Nov 5, 2018 at 12:27 PM Thorsten Schöning <[hidden email]> wrote:

>
> Guten Tag Ryan Schmidt,
> am Montag, 5. November 2018 um 04:45 schrieben Sie:
>
> > I'd be interested to know the resolution, since I use the GitHub
> > svn bridge daily. I'll hold off on upgrading past Subversion 1.10.x
> > for now but could you keep us informed about what GitHub does to solve this?
>
> Support of GitHub answered:
>
> > Thanks to your report our engineers are investigating the situation.
> > I don't have an ETA for a fix but we'll keep you updated.
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning

They've been good about support: I also bet they have a lot of recent
staff turnover with the purchase of their company by Microsoft.
Reply | Threaded
Open this post in threaded view
|

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

Branko Čibej
In reply to this post by Branko Čibej
On 04.11.2018 20:11, Branko Čibej wrote:

> On 04.11.2018 18:57, Thorsten Schöning wrote:
>> Guten Tag Branko Čibej,
>> am Sonntag, 4. November 2018 um 17:47 schrieben Sie:
>>
>>> I'm not sure what you mean by "handles more than only DAV successfully"
>> I thought it might be possible that GitHub answers differently but
>> properly, because the other check mentioned something about HTTP v2.
>> Because of TLS, I was unable to look at the requests and responses
>> then, but it's like you said, they don't provide DAV-headers in their
>> response to OPTION.
>>
>>> And yes, the HTTP/DAV specification requires that header to be present
>>> in the response.
>> Which you didn't care about before and things worked for some years
>> for some users.
> We made this change because users complained about unhelpful error
> messages when they tried to connect to a server that did not even
> implement HTTP/DAV. The error message was "Malformed XML in response"
> which wasn't exactly helpful for diagnosing the problem.
>
> I admit I didn't have GitHub in mind when I added this check. ...

I added a test case to our suite that tries the following command:

    svn info https://github.com/apache/subversion/trunk


It runs on one of our build slaves, so we'll know fairly soon when (if)
GitHub deploys a fix. And, of course, we'll also know if this feature
breaks again in future.

http://svn.apache.org/r1845942

-- Brane

Reply | Threaded
Open this post in threaded view
|

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

Branko Čibej
In reply to this post by Ryan Schmidt-10
On 05.11.2018 18:27, Thorsten Schöning wrote:

> Guten Tag Ryan Schmidt,
> am Montag, 5. November 2018 um 04:45 schrieben Sie:
>
>> I'd be interested to know the resolution, since I use the GitHub
>> svn bridge daily. I'll hold off on upgrading past Subversion 1.10.x
>> for now but could you keep us informed about what GitHub does to solve this?
> Support of GitHub answered:
>
>> Thanks to your report our engineers are investigating the situation.
>> I don't have an ETA for a fix but we'll keep you updated.


Has there been any further update from them on this issue?

In the meantime, I created this:

https://issues.apache.org/jira/browse/SVN-4789

It contains a patch for the Subversion client that hacks around GitHub's
bug, but it's a very messy hack indeed and I would prefer to not have it
in our code.

-- Brane

Reply | Threaded
Open this post in threaded view
|

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

Branko Čibej
On 15.11.2018 19:07, Thorsten Schöning wrote:
> Guten Tag Branko Čibej,
> am Donnerstag, 15. November 2018 um 18:21 schrieben Sie:
>
>> Has there been any further update from them on this issue?
> Sadly not and they didn't get in contact with you using dev@?

Nope; not now, and not ever. Sigh.

-- Brane

Reply | Threaded
Open this post in threaded view
|

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

Branko Čibej
In reply to this post by Branko Čibej
On 21.11.2018 15:23, Thorsten Schöning wrote:

> Guten Tag Branko Čibej,
> am Donnerstag, 15. November 2018 um 18:21 schrieben Sie:
>
>> Has there been any further update from them on this issue?
> News:
>
>> Thanks for following up. Our engineers have been able to reproduce
>> the error on our CI system and are working on a fix.
>> This issue is already a focus for our SVN team. However people who
>> are experiencing this issue can feel free to write in to
>> [hidden email] to report their own experience and we'll also let
>> them know when the issue is fixed.


Oh, that's nice.

-- Brane

Reply | Threaded
Open this post in threaded view
|

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

Nico Kadel-Garcia-2
On Wed, Nov 21, 2018 at 9:54 AM Branko Čibej <[hidden email]> wrote:

>
> On 21.11.2018 15:23, Thorsten Schöning wrote:
> > Guten Tag Branko Čibej,
> > am Donnerstag, 15. November 2018 um 18:21 schrieben Sie:
> >
> >> Has there been any further update from them on this issue?
> > News:
> >
> >> Thanks for following up. Our engineers have been able to reproduce
> >> the error on our CI system and are working on a fix.
> >> This issue is already a focus for our SVN team. However people who
> >> are experiencing this issue can feel free to write in to
> >> [hidden email] to report their own experience and we'll also let
> >> them know when the issue is fixed.
>
>
> Oh, that's nice.
>
> -- Brane

Can this be entirely sidestepped by using svn+ssh:// access instead of
HTTPS:// ? I'm not currently using any Subversion based access to
github, but it might provide a short-term workaround if it's
supported.
Reply | Threaded
Open this post in threaded view
|

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

Branko Čibej
On 22.11.2018 17:39, Nico Kadel-Garcia wrote:

> On Wed, Nov 21, 2018 at 9:54 AM Branko Čibej <[hidden email]> wrote:
>> On 21.11.2018 15:23, Thorsten Schöning wrote:
>>> Guten Tag Branko Čibej,
>>> am Donnerstag, 15. November 2018 um 18:21 schrieben Sie:
>>>
>>>> Has there been any further update from them on this issue?
>>> News:
>>>
>>>> Thanks for following up. Our engineers have been able to reproduce
>>>> the error on our CI system and are working on a fix.
>>>> This issue is already a focus for our SVN team. However people who
>>>> are experiencing this issue can feel free to write in to
>>>> [hidden email] to report their own experience and we'll also let
>>>> them know when the issue is fixed.
>>
>> Oh, that's nice.
>>
>> -- Brane
> Can this be entirely sidestepped by using svn+ssh:// access instead of
> HTTPS:// ? I'm not currently using any Subversion based access to
> github, but it might provide a short-term workaround if it's
> supported.

Only if GitHub provides that service. I doubt they do -- they're not
converting Git repositores to Subversion repositories, they're emulating
a Subversion HTTP server that gets information directly from git
repositories plus (presumably) some additional data to maintain stable
commit-id->revision mappings.

To support svn+ssh:// they'd have to emulate a second Subversion protocol.

-- Brane

P.S.: Clearly, the cause of the issue discussed in this thread is that
the emulation is incomplete.

Reply | Threaded
Open this post in threaded view
|

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

Branko Čibej
In reply to this post by Branko Čibej
On 09.12.2018 19:14, Thorsten Schöning wrote:

> Guten Tag Thorsten Schöning,
> am Mittwoch, 21. November 2018 um 15:23 schrieben Sie:
>
>>> Thanks for following up. Our engineers have been able to reproduce
>>> the error on our CI system and are working on a fix.
> Another two weeks have passed without any hint to the status of this
> problem from GH and I don't have the feeling that they are really
> working on this.
>
> Does anyone have any other infos? If not, does the SVN-team has any
> plans to release their workaround mentioned in the following ticket?
>
> https://issues.apache.org/jira/browse/SVN-4789

So, as I said in one of the mails referred to in that issue ... I'd
really prefer not to do that. Yet on the other hand, that GitHub->SVN
bridge is useful to users who're not locked into the gitficionado world.

My current thinking is that if GitHub can't fix their protocol emulation
by the time of the planned Subversion 1.12 release, we'll have to
seriously consider including this patch.

But I'd still rather not ...

-- Brane

Reply | Threaded
Open this post in threaded view
|

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

Nico Kadel-Garcia-2
On Sun, Dec 9, 2018 at 1:27 PM Branko Čibej <[hidden email]> wrote:

>
> On 09.12.2018 19:14, Thorsten Schöning wrote:
> > Guten Tag Thorsten Schöning,
> > am Mittwoch, 21. November 2018 um 15:23 schrieben Sie:
> >
> >>> Thanks for following up. Our engineers have been able to reproduce
> >>> the error on our CI system and are working on a fix.
> > Another two weeks have passed without any hint to the status of this
> > problem from GH and I don't have the feeling that they are really
> > working on this.
> >
> > Does anyone have any other infos? If not, does the SVN-team has any
> > plans to release their workaround mentioned in the following ticket?
> >
> > https://issues.apache.org/jira/browse/SVN-4789
>
> So, as I said in one of the mails referred to in that issue ... I'd
> really prefer not to do that. Yet on the other hand, that GitHub->SVN
> bridge is useful to users who're not locked into the gitficionado world.
>
> My current thinking is that if GitHub can't fix their protocol emulation
> by the time of the planned Subversion 1.12 release, we'll have to
> seriously consider including this patch.
>
> But I'd still rather not ...

I've reviewed the directions at
https://help.github.com/articles/support-for-subversion-clients/ , and
it's a fairly ugly hack, and work to do the integrated checkouts. The
last person I met who used it switched, with my help, to using git,
and using git-svn for access to their local Subversion repositories so
that they could commit working changes locally before submitting them
to the upstream Subversion repository. I recognize that this is *not*
the standard Subversion workflow, but I understood his desire to
publish upstream only the changes he wished to submit.

I'm afraid that the Subversion gateways to github.com are a niche
market, and not one likely to get eager support from github.com
without a compelling business reason to support them. The learning
curve to use git effectively is pretty steep, but the market for
Subversion-only users has been shrinking profoundly over the last
decade.
Reply | Threaded
Open this post in threaded view
|

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

Branko Čibej
On 09.12.2018 23:41, Nico Kadel-Garcia wrote:

> On Sun, Dec 9, 2018 at 1:27 PM Branko Čibej <[hidden email]> wrote:
>> On 09.12.2018 19:14, Thorsten Schöning wrote:
>>> Guten Tag Thorsten Schöning,
>>> am Mittwoch, 21. November 2018 um 15:23 schrieben Sie:
>>>
>>>>> Thanks for following up. Our engineers have been able to reproduce
>>>>> the error on our CI system and are working on a fix.
>>> Another two weeks have passed without any hint to the status of this
>>> problem from GH and I don't have the feeling that they are really
>>> working on this.
>>>
>>> Does anyone have any other infos? If not, does the SVN-team has any
>>> plans to release their workaround mentioned in the following ticket?
>>>
>>> https://issues.apache.org/jira/browse/SVN-4789
>> So, as I said in one of the mails referred to in that issue ... I'd
>> really prefer not to do that. Yet on the other hand, that GitHub->SVN
>> bridge is useful to users who're not locked into the gitficionado world.
>>
>> My current thinking is that if GitHub can't fix their protocol emulation
>> by the time of the planned Subversion 1.12 release, we'll have to
>> seriously consider including this patch.
>>
>> But I'd still rather not ...
> I've reviewed the directions at
> https://help.github.com/articles/support-for-subversion-clients/ , and
> it's a fairly ugly hack, and work to do the integrated checkouts. The
> last person I met who used it switched, with my help, to using git,
> and using git-svn for access to their local Subversion repositories so
> that they could commit working changes locally before submitting them
> to the upstream Subversion repository. I recognize that this is *not*
> the standard Subversion workflow, but I understood his desire to
> publish upstream only the changes he wished to submit.
>
> I'm afraid that the Subversion gateways to github.com are a niche
> market, and not one likely to get eager support from github.com
> without a compelling business reason to support them. The learning
> curve to use git effectively is pretty steep, but the market for
> Subversion-only users has been shrinking profoundly over the last
> decade.

So, what you're saying is that we have to revive and finish the ra_git
branch. :)

-- Brane

12