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), and (3) 10.0.1.1 was actually a typo for a valid peg-rev
specification and not something entirely different. All pretty
far-fetched, but it's not a parser's job to decide what is far-fetched.
So it's not instantly obvious how to be cleverer about this. I can see
two options:
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.
On Fri, 2008-05-23 at 22:32 +0200, Jens Seidel wrote:
> On Fri, May 23, 2008 at 09:17:50PM +0100, Julian Foad wrote:
> > Jens Seidel wrote:
> > >I noticed the following bug in the 1.5 branch:
> > >A IP address may bogusly interpreted as peg revision as demonstrated by
> > >
> > >$ svn log svn+ssh://svn@10.0.1.1
> > [...]
> > >svn: Syntax error parsing revision '10.0.1.1'
> >
> > That's unfortunate, but not a bug. It's a natural consequence of defining
>
> Not a bug? OK, I trust you. But a workaround should not be difficult.
>
> > the command-line syntax as
> >
> > PATH-OR-URL[@PEG]
>
> Never considered this as strong syntax definition.
>
> > There are various work-arounds: the canonical way to "escape" an argument
> > with no peg revision is to add an "@":
> >
> > $ svn log svn+ssh://svn@10.0.1.1@
> >
> > but in this particular example you might prefer to end the URL with "/":
> >
> > $ svn log svn+ssh://svn@10.0.1.1/
>
> No, this leads to the same error.
>
> I just asked to get the permission to file a bug. I didn't assumed the
> behaviour could be accepted but it is indeed not a big deal so it is OK
> for me.
>
> Jens
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-23 22:47:18 CEST