Problems accessing GitHub's SVN-bridge with SVN 1.11

[Thorsten Schöning]

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

The server at '[...]' does not support the HTTP/DAV protocol.
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

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: ***@AM-SoFT.de
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

[Thorsten Schöning]

Guten Tag Thorsten Schöning,

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. I've
already written to the GitHub support but nobody seemed to care yet.

https://groups.google.com/forum/#!topic/tortoisesvn/qaJQ_K9Wbb8

Mit freundlichen Grüßen,

Thorsten Schöning
--
Thorsten Schöning E-Mail: ***@AM-SoFT.de
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

[Daniel Shahaf]

Post by Thorsten Schöning
Guten Tag Thorsten Schöning,

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.

Post by Thorsten Schöning
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.)

[Thorsten Schöning]

Guten Tag Thorsten Schöning,

Post by Thorsten Schöning
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.
* 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

Post by Thorsten Schöning
if (svn_cstring_casecmp(key, "dav") == 0)
{
DAV: version-control,checkout,working-resource
DAV: merge,baseline,activity,version-controlled-collection
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth */
apr_array_header_t *vals = svn_cstring_split(val, ",", TRUE,
opt_ctx->pool);
opt_ctx->received_dav_header = TRUE;
[...]
/* SVN-specific headers -- if present, server supports HTTP protocol v2 */
else if (!svn_ctype_casecmp(key[0], 'S')
&& !svn_ctype_casecmp(key[1], 'V')
&& !svn_ctype_casecmp(key[2], 'N'))
{

Mit freundlichen Grüßen,

Thorsten Schöning
--
Thorsten Schöning E-Mail: ***@AM-SoFT.de
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

[Branko Čibej]

Post by Thorsten Schöning
Guten Tag Thorsten Schöning,

Post by Thorsten Schöning
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.
* 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

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

[Branko Čibej]

Post by Branko Čibej

Post by Thorsten Schöning
Guten Tag Thorsten Schöning,

Post by Thorsten Schöning
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.
* 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

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

[Thorsten Schöning]

Guten Tag Branko Čibej,

Post by Branko Čibej
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.

Post by Branko Čibej
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. 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...

Thank you both for your time anyway!

Mit freundlichen Grüßen,

Thorsten Schöning
--
Thorsten Schöning E-Mail: ***@AM-SoFT.de
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

[Branko Čibej]

Post by Thorsten Schöning
Guten Tag Branko Čibej,

Post by Branko Čibej
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.

Post by Branko Čibej
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. ...

Post by Thorsten Schöning
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

[Branko Čibej]

Post by Branko Čibej

Post by Thorsten Schöning
Guten Tag Branko Čibej,

Post by Branko Čibej
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.

Post by Branko Čibej
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

[Daniel Shahaf]

Post by Thorsten Schöning
Guten Tag Branko Čibej,

Post by Branko Čibej
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.

[Ryan Schmidt]

Post by Thorsten Schöning
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?

[Branko Čibej]

Post by Ryan Schmidt

Post by Thorsten Schöning
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

[Thorsten Schöning]

Guten Tag Ryan Schmidt,

Post by Ryan Schmidt
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?

Please don't wait for them answering me, ask GitHub yourself, write
them at Twitter or wherever you can reach them. Who am I in the end?
Maybe my mail didn't even pass their spam filter. :-)

I simply wrote to ***@github.com in lack for other sources and I
think we need to show GitHub that we are many, their SVN-bridge is
important to us and ask them to get in touch with the SVN-devs to fix
this.

https://groups.google.com/forum/#!topic/tortoisesvn/qaJQ_K9Wbb8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232945

Mit freundlichen Grüßen,

Thorsten Schöning
--
Thorsten Schöning E-Mail: ***@AM-SoFT.de
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

[Thorsten Schöning]

Guten Tag Ryan Schmidt,

Post by Ryan Schmidt
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?
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
--
Thorsten Schöning E-Mail: ***@AM-SoFT.de
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

[Nico Kadel-Garcia]

Post by Thorsten Schöning
Guten Tag Ryan Schmidt,

Post by Ryan Schmidt
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?
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.

[Branko Čibej]

Post by Thorsten Schöning
Guten Tag Ryan Schmidt,

Post by Ryan Schmidt
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?
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

[Thorsten Schöning]

Guten Tag Branko Čibej,

Post by Branko Čibej
Has there been any further update from them on this issue?

Sadly not and they didn't get in contact with you using dev@? I've
looked at that once in a while but couldn't see anything of interest.

Mit freundlichen Grüßen,

Thorsten Schöning
--
Thorsten Schöning E-Mail: ***@AM-SoFT.de
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

[Branko Čibej]

Post by Thorsten Schöning
Guten Tag Branko Čibej,

Post by Branko Čibej
Has there been any further update from them on this issue?

Nope; not now, and not ever. Sigh.

-- Brane

[Thorsten Schöning]

Guten Tag Branko Čibej,

Post by Branko Čibej
Has there been any further update from them on this issue?
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
them know when the issue is fixed.

Mit freundlichen Grüßen,

Thorsten Schöning
--
Thorsten Schöning E-Mail: ***@AM-SoFT.de
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

[Branko Čibej]

Post by Thorsten Schöning
Guten Tag Branko Čibej,

Post by Branko Čibej
Has there been any further update from them on this issue?
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
them know when the issue is fixed.

Oh, that's nice.

-- Brane

[Nico Kadel-Garcia]

Post by Branko Čibej

Post by Thorsten Schöning
Guten Tag Branko Čibej,

Post by Branko Čibej
Has there been any further update from them on this issue?
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
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.

[Branko Čibej]

Post by Nico Kadel-Garcia

Post by Branko Čibej

Post by Thorsten Schöning
Guten Tag Branko Čibej,

Post by Branko Čibej
Has there been any further update from them on this issue?
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
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.

[Thorsten Schöning]

Guten Tag Branko Čibej,

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.

If they really didn't fix it until 1.12, they surely won't ever
anymore. Maybe this gives you enough time to discuss this
fundamentally and tell people what they can expect for issues like
this one in future from the SVN-team?

It seems clear to me that the issue would need to be fixed by GH, but
your are able to workaround it somewhat easily. But this is only one
issue, what in case of another one easy like this or more difficult?
In theory 1.12 could break something different for some reason and
people would need to stick with 1.10 for at least a year then.

If you come to the conclusion that you don't do this kind of hacking
anymore or even at all including this issue, users of the SVN-bridge
would simply need to change their workflow to something else. I'm
only using the bridge because it was the easiest way to stay with my
former workflow and how I manage some versioned libs.

Or do you think it's not worth discussing that fundamentally (yet)?

Mit freundlichen Grüßen,

Thorsten Schöning
--
Thorsten Schöning E-Mail: ***@AM-SoFT.de
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

[Branko Čibej]

Post by Thorsten Schöning
Guten Tag Branko Čibej,

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.

If they really didn't fix it until 1.12, they surely won't ever
anymore. Maybe this gives you enough time to discuss this
fundamentally and tell people what they can expect for issues like
this one in future from the SVN-team?
It seems clear to me that the issue would need to be fixed by GH, but
your are able to workaround it somewhat easily. But this is only one
issue, what in case of another one easy like this or more difficult?

Exactly, this is why I'd prefer not to implement a specific hack for
GitHub in our code. If we made it a policy to support one broken server,
everyone would expect us to do so for the N+1st broken server, too ...
it's simply unmanageable in the long run.

Post by Thorsten Schöning
In theory 1.12 could break something different for some reason and
people would need to stick with 1.10 for at least a year then.

Ah, but we have a test in our test suite now (for this particular case). :)

Post by Thorsten Schöning
If you come to the conclusion that you don't do this kind of hacking
anymore

Just to point out: it' snot "any more"; we've never had any
vendor-specific hacks in our code.

Well actually that's not quite true, we still have a (build-time) hack
for Microsoft's ASP.Net, which could not abide having the '.svn'
directory in its project tree; but that was a client-side, compile-time
hack for a misfeature that had no workaround.

Post by Thorsten Schöning
or even at all including this issue, users of the SVN-bridge
would simply need to change their workflow to something else. I'm
only using the bridge because it was the easiest way to stay with my
former workflow and how I manage some versioned libs.
Or do you think it's not worth discussing that fundamentally (yet)?

It is surely worth discussing, but please, such discussions really
should happen on our dev@ list, not the users@ list. Feel free to start
a thread there.


-- Brane

[Nathan Hartman]

Perhaps Github's customers will just need to press a little bit
harder for a fix to be applied at Github's end?

Agreed. The squeaky wheel gets the grease.

[Nico Kadel-Garcia]

Post by Thorsten Schöning
Guten Tag Thorsten Schöning,

Post by Branko Čibej
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.

[Branko Čibej]

Post by Nico Kadel-Garcia

Post by Thorsten Schöning
Guten Tag Thorsten Schöning,

Post by Branko Čibej
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

[Nico Kadel-Garcia]

Post by Branko Čibej

Post by Nico Kadel-Garcia

Post by Thorsten Schöning
Guten Tag Thorsten Schöning,

Post by Branko Čibej
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

If that tool supports using an upstream git repository on a Subversion
client..... maybe? If that could be accomplished in some reasonable
amount of time? But I'd be *extremely* leery of connecting Subversion
clients, which rely on the mothership being the sources of all change
revisions, to an upstream git server. As distasteful s it may be to
Subversion fans, I'm saying the time is better spent in most
commercial or development environments learning to use git-svn so you
can get used to a git workflow and use it, as needed, to talk to the
Subversion servers. It also permits cloning and local development of a
Subversion repository without asking permission to write branches. It
is, in fact, what I used the last time I submitted patches to
Subversion itself. (Which has been a long time, I admit, my suggested
patches have never been that critical.)

[Branko Čibej]

Post by Thorsten Schöning
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

The server at '[...]' does not support the HTTP/DAV protocol.
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.

Post by Thorsten Schöning
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

[Branko Čibej]

Post by Branko Čibej

Post by Thorsten Schöning
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

The server at '[...]' does not support the HTTP/DAV protocol.
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.

[Nico Kadel-Garcia]

Post by Thorsten Schöning
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

The server at '[...]' does not support the HTTP/DAV protocol.
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..

Post by Thorsten Schöning
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
--
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

[Thorsten Schöning]

Guten Tag Nico Kadel-Garcia,

Post by Nico Kadel-Garcia
Can you switch to using TortoiseGit locally, and avoid the extra
compatibility layers?

My use case might be special: I have one large libs-repo for many
different projects and that contains committed libs and some using
svn:externals. Everyone checking out this libs-repo with any
SVN-client, shell, Tortoise, Eclipse etc., gets everything from public
SNV servers or even GitHub as needed.

TortoiseGit is not of much help in this setup. Yes, that might change
in future and could be handled totally different and all, but
currently it is the way it is anbd I hope GitHub fixes things.

Mit freundlichen Grüßen,

Thorsten Schöning
--
Thorsten Schöning E-Mail: ***@AM-SoFT.de
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