Hi, I would like to propose extending the RA-SVN tunnel callback mechanism so that it can optionally handle plain svn:// connections as well.
I am not subscribed to this mailing list, so please CC me directly on replies. Problem When connecting to an svn:// URL, libsvn_ra_svn currently opens a TCP connection directly to the server. HTTP/HTTPS connections can be configured to use a proxy, while svn+<tunnel>:// connections can be handled through the check_tunnel_func / open_tunnel_func callbacks. However, for a plain svn:// connection there is currently no corresponding callback path. This makes it difficult for an application embedding Subversion to route an svn:// connection through its own proxy, forwarder, or other custom transport. Proposal My idea is to allow the existing tunnel callbacks to optionally handle plain svn:// connections too. For a plain svn:// URL: - If check_tunnel_func and open_tunnel_func are installed, call check_tunnel_func(tunnel_baton, NULL). - If it returns TRUE, call open_tunnel_func with tunnel_name == NULL. - Otherwise, retain the existing behavior and open the TCP socket directly. In this scheme, NULL would mean "plain svn:// connection", while a non-NULL tunnel name would continue to represent an svn+<tunnel>:// connection. Existing callers that do not opt into this behavior would therefore continue to use the current direct TCP connection. Proof of concept I made a small proof-of-concept change in subversion/libsvn_ra_svn/client.c along these lines: https://github.com/holdxen/svn/blob/main/patches/subversion/default-tunnel.patch This is only a proof of concept at this point. I would like to confirm the intended API/design before preparing a complete patch and tests. In particular, I would appreciate feedback on the following questions: 1. Would using tunnel_name == NULL to represent a plain svn:// connection be an acceptable extension of the existing tunnel callback semantics? 2. Is extending check_tunnel_func / open_tunnel_func preferable here, or would a separate callback/API for opening plain RA-SVN connections be considered cleaner? 3. Are there compatibility concerns with existing users of these callbacks that I should take into account? If this approach looks reasonable, I can prepare the corresponding tests, documentation updates, and a proper patch for review. Thanks,
