> That would work for svn:// urls, but it won't work for svn+ssh:// url.
> You have to understand here the difference between those two. The svn://
> access is handled by Subversion, but the svn+ssh:// access is handled by
> your ssh setup.
Thanks for the explanation, and fair enough. However, as far as I can
tell, not using the port specification for SSH connections is still an
implementation issue, not a design decision. Well, I cannot tell if it
is or is not a design decision, but I can't think of a situation where
it would be appropriate. That is, a situation where it would be wrong or
unusable to have the port specification work as expected in an
> And that doesn't understand port numbers in the URI.
Well, no. But that's because it never sees the URI; the only parameters
it receives are 'user@host' and the 'svnserve -t' command. So the SSH
program never gets a chance of understanding the port number, not even
if we would replace it with one of our own that would.
> It's not an implementation issue of TSVN or Subversion. Once you use
> SSH, the only thing Subversion is responsible for is the data sent and
> received. _How_ that data is transferred is completely up to the SSH
> setup. Subversion has no way to interfere with that.
That is not entirely true. The SSH client supports a command-line
parameter to change the port. At least, Plink, the out-of-the-box SSH
client accepts one, and I imagine most if not all SSH clients out there do.
A simple solution would be to parse the port number from the URL, and
pass it on to the SSH client using the appropriate command-line
parameter. The default could be an extra parameter '-P <port>' to the
included Plink application, and should be configurable so that it can
interoperate with other SSH clients as well.
Alternatively, a wrapper application or script could get passed the
entire URI, decompose it as desired and pass it on to any SSH client
with the right parameter set. All of this with default applications and
settings that work out of the box, of course, but still modifiable by
the end user for special cases.
Just a thought.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Oct 19 09:11:29 2004