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
