5

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

I've already written to the support but didn't get any response yet. Maybe someone here knows already if this is a temporary issue only or permanent? Maybe this problem doesn't happen for other users at all for some reason?

Thanks!

Thorsten Schöning
  • 3,501
  • 2
  • 25
  • 46
  • Others have the same problem: https://groups.google.com/forum/#!topic/tortoisesvn/qaJQ_K9Wbb8 – Thorsten Schöning Nov 04 '18 at 15:39
  • There was an intentional change by the SVN-devs to implement more strict error checking on protocol level leading to the problem and they say it won't change on their site: https://mail-archives.apache.org/mod_mbox/subversion-users/201811.mbox/ – Thorsten Schöning Nov 04 '18 at 17:46
  • IMHO, GitHub's "support for SVN clients" was never working as it should be. Yes, it worked for simple checkout, export and commit operations but that is not what "support" means. Anything more complex resulted in awkward errors. – bahrep Nov 05 '18 at 16:42
  • 1
    @bahrep They supported everything I and many others seem to only need, including `svn:externals`, which in my opinion is somewhat complex already. – Thorsten Schöning Nov 06 '18 at 08:21

4 Answers4

7

Does not work here anymore with ALL github repositories! Using latest TortoiseSVN 1.11.0.

I've tried with version 1.10 of TortoiseSVN which still works, so this looks like a problem with TortoiseSVN 1.11 (which is linked against SVN 1.11).

Stefan
  • 104
  • 2
  • 3
    Because of the wording of the error messages I simply didn't thought of client side problems, but TortoiseSVN really is the problem. I recently upgraded to 1.11.0 as well and switching back to 1.10 resolves the problems. Therefore I accept this answer, as it is the correct one in the concrete context of my problem. Next step will be to further debug why this occurs. – Thorsten Schöning Nov 04 '18 at 09:22
4

This particular problem has been resolved on GitHub's side (as of 19 Dec 2018), please, see the Outdated section below.

However, you can get the error The server at '[...]' does not support the HTTP/DAV protocol. in other cases such as

svn info https://stackoverflow.com/ svn: E170013: Unable to connect to a repository at URL 'https://stackoverflow.com' svn: E175003: The server at 'https://stackoverflow.com' does not support the HTTP/DAV protocol

Outdated:

Use Subversion 1.10 clients as a workaround.

Because of some changes in the latest Subversion 1.11.0 release, the newest SVN 1.11 clients do not work with GitHub's SVN bridge anymore and produce an error. Let's hope for a bugfix on SVN or GitHub's side soon.

You can find more information in this users@ Apache Subversion mailing list thread: https://lists.apache.org/thread.html/90c028421ac86f787c2101ab61a70ec5fa0a6f4d617a8b87be802e5c@%3Cusers.subversion.apache.org%3E

bahrep
  • 29,961
  • 12
  • 103
  • 150
1

No, it is just a bug on GitHub side.

Check out the below... (I found this messages from the link uploaded by bahrep)

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.

OTOTO
  • 198
  • 9
1

Warning: starting Jan. 2024, GitHub will do more than shutdown its support to SVN clients.

Sunsetting Subversion support (Mat Copper)

Hello from Git Systems, the team that works on the Subversion subsystem at GitHub.

As of January 8, 2024 (about a year from now), we will sunset Subversion support completely on GitHub.com.
A release of GitHub Enterprise Server sometime in early 2024 will also remove Subversion support. Read on for more details.

In 2010, when GitHub introduced Subversion support, the version control landscape was very different. Many customers were using centralized version control systems.
Subversion was already 10 years old and in good company with other centralized systems, while Git was still a relative newcomer. At that point in time, it was not yet clear that distributed version control would eventually take over, and even less clear that Git would be the dominant system.
By natively supporting Subversion on top of a Git backend, GitHub made it easier for customers to move to Git while changing their workflows over in a gradual way.

Fast forward to now, and wow, have things changed. Git enjoys up to 94% usage by developers, and Subversion is a lot rarer in the wild than it used to be.
Our traffic numbers inside GitHub back this up: fewer than 0.02% of requests made to the Git backend come through a Subversion endpoint, and only about 5,000 repositories see even a single Subversion request each month.
It’s clear that Subversion support is no longer helping people migrate to Git.

But hey, if the Subversion system just works and doesn’t bother anyone, there’s no reason to make any changes, right?
The reality is that there’s an ongoing maintenance cost to any software, and that goes extra for public-facing services on the internet. As the use of GitHub has evolved and the number of Subversion requests has declined dramatically, we plan to focus our efforts entirely on Git.

Why do people still use Subversion on GitHub, anyhow?
Besides simple inertia, there were workflows which Git didn’t support until recently.
The main thing we heard when speaking with customers and communities was checking out a subset of the repository–a single directory, or only the latest commit.
I have good news: with sparse checkout, sparse index, and partial clone, Git can now do a pretty decent job at these workflows.

We will maintain Subversion support until January 8, 2024 on GitHub.com.

After that date, it will be turned off and removed.
Late in 2023, we’ll run a few hours-long and then day-long brownouts to help flush out any remaining use of the feature.
The next version of GitHub Enterprise Server to ship after January 8, 2024, will also remove Subversion support.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250