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

RE: configurable svn+ssh remote tunnel commands

From: Bert Huijben <bert_at_qqmail.nl>
Date: Wed, 27 Aug 2014 12:24:41 +0200

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: woensdag 27 augustus 2014 11:38
> To: dev_at_subversion.apache.org
> Subject: configurable svn+ssh remote tunnel commands
> Apparently people are having trouble in some configurations with
> the hardcoded 'svnserve -t' default remote tunnel command.
> One problematic case seems to involve running a GUI Subversion
> client on a Mac against a server on localhost via svn+ssh.
> See #svn chat log at:
> http://colabti.org/irclogger/irclogger_log/svn?date=2014-08-26#l248
> As far as I understand the situation, apple is shipping an old svnserve
> in /usr/bin and the user would prefer running a more recent
> /usr/local/bin/svnserve.
> Additionally, overriding per-user environment variables like PATH
> seems to be a very difficult thing to do. I can't judge if this is
> really the case since I don't use MacOS at all.
> The user is requesting a config knob to override the default, to be
> able to specify a full path to svnserve and add other flags to
> svnserve's invocation as desired. This is indeed a fairly trivial
> change. Do we want to add this?
> Note that, with ssh keys, the server can override the tunnel command
> requested by the client, which is another possible workaround.
> This is diff is untested, just a proof of concept.

I think that if we add support for this, we should use the servers file, to
allow setting it globally but also overriding this option per server.

But really: I think the server administrator should fix the config, instead
of making all users do it per install.
(You can probably even change it yourself on the server by updating your

Received on 2014-08-27 12:28:02 CEST

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

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