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

ra_svn tunnel configuration

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2002-12-05 14:32:11 CET

Okay, so the previous conversation decided that the client will use
configuration information to decide when to use a tunnel agent for an
svn:// URL. It remains to be decided how this fits into the
configuration structure.

Right now there is a file ~/.subversion/servers (renamed from
~/.subversion/proxies?) which contains information about HTTP proxies.
There appears to be a dedicated svn_subr API for reading this file,
which seems to be a layering violation. I can:

  * Worm my way into this file, rendering it overloaded and no longer
    specific to HTTP. Inside a proxy group (which we'd now call a
    server group), host/port/username/password/timeout would specify
    HTTP proxies, while tunnel-agent would specify svn tunnel agents.

  * Create a new file, ~/.subversion/tunnel-agents (or whatever), with
    a similar structure to ~/.subversion/server.

  * Create a new section [tunnel-agents] (or whatever) in
    ~/.subversion/config. It might look like:

    [tunnel-agents]
    agent1 = *.collab.net : ssh %h svnserve -r /usr/local/repos
    agent2 = myhost.mit.edu : ssh -l fred %h svnserve

    where the variable names have no meaning except when it comes to
    overriding between the system and user config files.

    (Is it best to have the hostname and "svnserve" explicit in the
    agent specification like this? Or should the agent string just
    look like "ssh", with the hostname and "svnserve" appended
    automatically? I'm not sure.)

    (Hm. I was going to pass the command through /bin/sh when I was
    done creating it, but that's not very Windows-friendly. I can't
    use system() because I need the input and output pipes.
    Suggestions?)

None of these options give me a warm feeling inside. Which do people
find least offensive? Or are there better options?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 5 14:32:56 2002

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.