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