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.)
