You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Thorsten Schöning <ts...@am-soft.de> on 2018/12/09 18:14:51 UTC

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.Schoening@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

Posted by Branko Čibej <br...@apache.org>.
On 10.12.2018 15:09, Nathan Hartman wrote:
> On Mon, Dec 10, 2018 at 5:14 AM Stefan Sperling <st...@elego.de> 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

Posted by Nathan Hartman <ha...@gmail.com>.
On Mon, Dec 10, 2018 at 5:14 AM Stefan Sperling <st...@elego.de> 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

Posted by Stefan Sperling <st...@elego.de>.
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

Posted by Branko Čibej <br...@apache.org>.
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

Posted by Thorsten Schöning <ts...@am-soft.de>.
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.Schoening@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

Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Mon, Dec 10, 2018 at 12:30 AM Branko Čibej <br...@apache.org> wrote:
>
> On 09.12.2018 23:41, Nico Kadel-Garcia wrote:
> > On Sun, Dec 9, 2018 at 1:27 PM Branko Čibej <br...@apache.org> 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

Posted by Branko Čibej <br...@apache.org>.
On 09.12.2018 23:41, Nico Kadel-Garcia wrote:
> On Sun, Dec 9, 2018 at 1:27 PM Branko Čibej <br...@apache.org> 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

Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sun, Dec 9, 2018 at 1:27 PM Branko Čibej <br...@apache.org> 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

Posted by Branko Čibej <br...@apache.org>.
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