[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Bug: IP address bogusly interpreted as peg revision

From: Troy Curtis Jr <troycurtisjr_at_gmail.com>
Date: Sun, 25 May 2008 14:04:58 -0500

On Sun, May 25, 2008 at 1:56 PM, Troy Curtis Jr <troycurtisjr_at_gmail.com> wrote:
>>>> 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.
>>
>> Oh, so it does! That's a bug: we're not supposed to be looking for a peg
>> after the last "/". I suspect what is happening is the path is being
>> "canonicalised" first, which whould strip off the final "/", but that's
>> wrong and Troy Curtis is already working on a patch to fix the parsing of
>> peg-revs with repository-relative URLs, and hopefully that will fix this
>> too.
>>
>
> Long Answer:
>
> Actually what is happening is this:
> - Inside svn_client_args_to_target_array():
> - It is determined there is no peg revision (the peg splitting logic
> bails on the trailing slash)
> - Then the string 'svn+ssh://svn@10.0.1.1/' is passed the
> canonicalising function
> - The trailing slash is removed to make it canonical
> - The result is passed back in the targets array
> - Inside subsequent command processing functions:
> - At some point the target is passed to svn_opt_parse_path() to
> extract the peg revision (if any)
> - svn_opt_parse_path() does not see a peg revision (because we
> removed the trailing slash) and so interprets
> 10.0.1.1 as a peg, and an invalid one at that.
>
> The "solution" here is the only proper way to "escape" the '@' inside
> a path is by putting a trailing '@' in the target string.
>
> Short Answer: It's not a bug, it's a feature! :)
>
> Troy
>
>>
>>> 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.
>>
>> Thanks. If you'd like to help see if Troy's patch fixes the above usage,
>> that would be great. (No worries if not.) His last revision of the patch is
>> at <http://svn.haxx.se/dev/archive-2008-05/0477.shtml> and he hopes to send
>> a revised version soon.
>>
>> - Julian
>>
>
You know after thinking about it I could "fix" this behavior. I'm
working on my revised patch right now and I think the trailing slash
workaround would work if I returned "@" for no peg revision found
instead of "" in my new fangled svn_opt__split_arg_at_peg_revision()
function. This would mean that every single target coming out of the
svn_client_args_to_target_array() would have a peg revision, but some
of them would be blank.

This actually changes the current CLI behavior (in that the trailing
slash thing would not have worked before), but is it something that we
want to include?

Troy

-- 
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.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-25 21:05:11 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.