[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Mon, 10 Dec 2018 01:05:19 -0500

On Mon, Dec 10, 2018 at 12:30 AM Branko Čibej <brane_at_apache.org> wrote:
> On 09.12.2018 23:41, Nico Kadel-Garcia wrote:
> > On Sun, Dec 9, 2018 at 1:27 PM Branko Čibej <brane_at_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.)
Received on 2018-12-10 07:05:44 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.