[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: Tue, 27 May 2008 11:16:24 -0500

On Sun, May 25, 2008 at 2:04 PM, Troy Curtis Jr <troycurtisjr_at_gmail.com> wrote:
> 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@
>>>>> but in this particular example you might prefer to end the URL with "/":
>>>>> $ svn log svn+ssh://svn@
>>>> 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@' 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
>> 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

It turns out this simplistic approach doesn't work. Surprising, no?

My proposal hinged on the assumption that all the downstream functions
handle peg revision and so we can just stick an empty peg revision on
any target that doesn't already have one. But of course this isn't
true of commands expecting only paths and I suspect now that I think
of it there may be cases where peg revs aren't actually handled for
certain url cases either.

Of course it took me actually trying to make the change and getting a
load of test failures to figure that out. :)


"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-27 18:16:39 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.