Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On 19.12.2018 09:18, Thorsten Schöning wrote: > Guten Tag Thorsten Schöning, > am Mittwoch, 21. November 2018 um 15:23 schrieben Sie: > >> News: > The following arrived today: > >> Just wanted to let you know that this issue should now be resolved! >> Let us know how you go. >> Cheers, >> Simon >> GitHub Support > Things seem to work again for me using the most current version of > TortoiseSVN. What's about the newly added CI-test? Should be fine now > I guess. Yes, in fact that test unexpectedly passing alerted me to the change on GitHub sometime last night. They added that 'DAV: 1' response header and are now passing Subversion's checks again. Thanks to everyone who helped track this down and nagged GitHub for the fix! -- Brane
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
Guten Tag Thorsten Schöning, am Mittwoch, 21. November 2018 um 15:23 schrieben Sie: > News: The following arrived today: > Just wanted to let you know that this issue should now be resolved! > Let us know how you go. > Cheers, > Simon > GitHub Support Things seem to work again for me using the most current version of TortoiseSVN. What's about the newly added CI-test? Should be fine now I guess. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@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
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On 10.12.2018 15:09, Nathan Hartman wrote: > On Mon, Dec 10, 2018 at 5:14 AM Stefan Sperling wrote: > >> 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. GitHub has fixed their Subversion bridge. This was the first indication: https://ci.apache.org/builders/svn-x64-macosx-local/builds/2744/steps/Test%20ra_local%2Bfsfs/logs/faillog And here's the proof: $ svn --version --quiet 1.11.0 $ svn info https://github.com/apache/httpd/trunk/ Path: trunk URL: https://github.com/apache/httpd/trunk Relative URL: ^/trunk Repository Root: https://github.com/apache/httpd Repository UUID: 908ae0b0-d39a-fa95-1ef9-ce57b7db7bff Revision: 59645 Node Kind: directory Last Changed Author: stefan.eissing Last Changed Rev: 59634 Last Changed Date: 2018-12-18 14:58:31 +0100 (Tue, 18 Dec 2018) -- Brane
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On Mon, Dec 10, 2018 at 5:14 AM Stefan Sperling wrote: > 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.
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On 10.12.2018 10:08, Thorsten Schöning wrote: > Guten Tag Branko Čibej, > am Sonntag, 9. Dezember 2018 um 19:27 schrieben Sie: > >> 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. > 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). :) > 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. > 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
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On Mon, Dec 10, 2018 at 10:08:10AM +0100, Thorsten Schöning wrote: > 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)? Perhaps Github's customers will just need to press a little bit harder for a fix to be applied at Github's end? As Branko explained earlier, the fix amounts to sending another HTTP header in the response. Github's web developers should be able to manage that...
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
Guten Tag Branko Čibej, am Sonntag, 9. Dezember 2018 um 19:27 schrieben Sie: > 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: thorsten.schoen...@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
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On Mon, Dec 10, 2018 at 12:30 AM Branko Čibej wrote: > > On 09.12.2018 23:41, Nico Kadel-Garcia wrote: > > On Sun, Dec 9, 2018 at 1:27 PM Branko Čibej 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 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.)
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On 09.12.2018 23:41, Nico Kadel-Garcia wrote: > On Sun, Dec 9, 2018 at 1:27 PM Branko Čibej 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
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On Sun, Dec 9, 2018 at 1:27 PM Branko Čibej 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.
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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 Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@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
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On 22.11.2018 17:39, Nico Kadel-Garcia wrote: > On Wed, Nov 21, 2018 at 9:54 AM Branko Čibej 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 supp...@github.com 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.
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On Wed, Nov 21, 2018 at 9:54 AM Branko Čibej 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 > >> supp...@github.com 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.
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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 >> supp...@github.com to report their own experience and we'll also let >> them know when the issue is fixed. Oh, that's nice. -- Brane
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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 > supp...@github.com to report their own experience and we'll also let > them know when the issue is fixed. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@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
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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@? 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: thorsten.schoen...@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
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On Mon, Nov 5, 2018 at 12:27 PM 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. > > 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.
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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 -- Thorsten Schöning E-Mail: thorsten.schoen...@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
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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? 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 supp...@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: thorsten.schoen...@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
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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?
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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.
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
Guten Tag Nico Kadel-Garcia, am Sonntag, 4. November 2018 um 19:42 schrieben Sie: > 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: thorsten.schoen...@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
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On Sun, Nov 4, 2018 at 10:05 AM 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 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: thorsten.schoen...@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 >
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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. 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: thorsten.schoen...@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
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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.
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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 #!/bin/bash if [ -z "$1" ]; then echo "Usage: $0 " >&2 exit 2 fi HOST=$(echo "$1" | sed -e 's%^https*://\([^/]*\).*$%\1%') set -x curl -i -X OPTIONS \ -H "Host: $HOST" \ -H 'User-Agent: SVN/1.11.0' \ -H 'Content-Type: text/xml' \ -H 'DAV: http://subversion.tigris.org/xmlns/dav/svn/depth' \ -H 'DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo' \ -H 'DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops' \ --data-raw '' \ "$1"
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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:
> if (svn_cstring_casecmp(key, "dav") == 0)
> {
> /* Each header may contain multiple values, separated by commas, e.g.:
>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: thorsten.schoen...@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
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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.)
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
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. 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: thorsten.schoen...@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
