Oops... forgot to group reply...
I have a personal pet peeve with using part of the URL to determine
access method. I have a repository which is accessable via svn,
svn+ssh, http, and https. Depending on who I'm talking to, I get
URLs using any of these protocols which I may not prefer. It
results in a lot of manual rewriting of URLs which, for someone not
familiar with my repository, is unlikely to be obvious. Say I send
someone a URL like svn://repo.company.com/svn/trunk but they want
or need to use http instead---say they're behind a firewall that
requires use of an http proxy that won't let you connect to
non-http ports, or their client doesn't support the authentication
mechanism my svn repo supports. How are they supposed to know that
they can rewrite the URL? I have to explain it to them. Grr.
Wouldn't it be better to use service records in DNS to resolve all
viable protocols that can be used to access a repository. The
client can then attempt to autoselect, or prompt the user to select
one mechanism. I'm thinking of records something like this:
_svn._http.repo.company.com IN SRV 10 10 80 repo.company.com
_svn._https.repo.company.com IN SRV 10 10 443 repo.company.com
_svn._svn.repo.company.com IN SRV 10 10 3690 repo.company.com
_svn._svn_ssh.repo.company.com IN SRV 10 10 22 repo.company.com
I'd then always use svn://repo.company.com/svn/trunk URLs to the
repository, but each client would have the option to switch to
http, https, or svn+ssh based on the users preference,
autodetection of available access, or the priority in the service
records themselves.
Thoughts?
--
Oracle Confidential Information
Alec.Kloss_at_oracle.com Oracle Middleware
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x432B9956
- application/pgp-signature attachment: stored
Received on 2008-10-30 14:57:44 CET