Stefan Petri wrote:
> I have stumbled across several cases where access via tunneling failed
> because the remote svnserve binary was not in a system default search
> path. The subversion FAQ and manual show the workaround via tweaking > ssh
> key configuration, but I have several cases where that is not
> applicable. So, here is 4-line patch , which takes the command to invoke
> from the environment variable SVN_REMCMD. If that is not set, the > remote
> command defaults to "svnserve".
Has anybody had a chance to look at this patch? If no one does anything
with it in the next few days, I'll file an issue.
> subversion/libsvn_ra_svn/client.c use SVN_REMCMD to override hardcoded
> To circumvent problems with the hardcoded invocation of "svnserve" on
> the remote end of tunnels, look for environment variable SVN_REMCMD.
> Fall back to "svnserve" if that is not set.
> This helps when e.g. the svnserve command is not in the remote systems
> default search path, and ssh key trickery as descibed in the > Subversion
> manual is not applicable.
> --- subversion-1.4.0/subversion/libsvn_ra_svn/client.c-orig
> +++ subversion-1.4.0/subversion/libsvn_ra_svn/client.c
> @@ -451,6 +451,10 @@
> apr_size_t len;
> apr_status_t status;
> int n;
> + char *remcmd;
> + remcmd = getenv("SVN_REMCMD");
> + if (NULL == remcmd) remcmd = "svnserve";
> /* Look up the tunnel specification in config. */
> cfg = config ? apr_hash_get(config, SVN_CONFIG_CATEGORY_CONFIG,
> @@ -499,7 +503,7 @@
> *argv = apr_palloc(pool, (n + 4) * sizeof(char *));
> memcpy(*argv, cmd_argv, n * sizeof(char *));
> (*argv)[n++] = svn_path_uri_decode(hostinfo, pool);
> - (*argv)[n++] = "svnserve";
> + (*argv)[n++] = remcmd;
> (*argv)[n++] = "-t";
> (*argv)[n] = NULL;
Received on Fri Sep 29 00:47:36 2006