[Greg Hudson]
> The URL you mentioned *could* be interpreted as the repository "svn
> +ssh://svn" at the mis-specified peg rev 10.0.1.1. This
> interpretation would only make sense if (1) "svn" was a valid
> hostname with your resolver configuration, (2) there was a repository
> located at the virtual root of that host (i.e. no repository path as
> part of the URL; it could be located anywhere in the filesystem via
> server configuration),
Server configuration, for svn+ssh://? I seem to recall that svnserve
doesn't honor -r if -t is set. If that's true, this repository would
have to be in the literal root of your filesystem.
> 1. We could make peg-rev processing aware of the URL syntax and ignore
> '@' signs which occur before the path component, but that would cut off
> the ability to do scheme://hostname@pegrev for a repository located at
> the virtual root of a host. One could still use
> scheme://hostname/@pegrev so this might be acceptable.
>
> 2. We could make peg-rev processing aware of the peg-rev syntax and
> ignore IP addresses, hostnames, etc.. That would, at the very least,
> lead to bad error messages; if you misspell or misremember what a
> peg-rev specification should look like, instead of being told you have
> an invalid peg-rev specification, you get a path-not-found error.
3. Consider any @ before a / to not be a peg rev delimiter. (Or is
there some peg rev syntax that allows / in it?)
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Received on 2008-05-24 02:11:21 CEST