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

Re: [PATCH] ISSUE #3193 Fix peg revision parsing for CLI repository root relative urls.

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 23 May 2008 11:40:38 +0100

Troy Curtis Jr wrote:
> On Thu, May 22, 2008 at 6:07 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
>>From the point of view of parsing command-line syntax, I think removing the
>>peg revision specifier comes logically before canonicalising the rest of the
>>argument. Therefore, may I recommend not making the
>>svn_opt__arg_canonicalize_path()/_url() functions "cope with" a peg
>>revision, but leave them as they were, to operate on just a path or URL.
>>Instead, make your split_arg_at_peg_revision() function semi-public (maybe
>>called "svn_opt__arg_split_at_peg") and use it where previously the
>>*_args_to_target_array*() and other functions did their own parsing.
>>If your split_arg_at_peg_revision() will return the peg string with the "@"
>>still on it, then it could represent "no peg" with either NULL or the empty
>>string. I suggest it should never return NULL but rather the empty string
>>when there is no peg, so that callers can simply re-concatenate the peg
>>without checking for NULL. This seems a reasonable way to go for now, given
>>that (as you point out) some client functions still want to add the peg back
>>on and then take it off again later. In the long term, the clean way to
>>organise it would be for this initial splitting to pass the peg back
>>separately (without its "@") and for the path and the peg to be passed
>>around separately thereafter. But there's no need to go into that now.
>>That seems to make it all simpler. Does that make sense and is there
>>anything else I could help with? It would be great to see an update when you
>>have time. Thanks.
> That would certainly work, I was just trying to keep from having to
> put another implementation in the relative url parsing block of the
> code.

I don't quite follow what you mean by this.

> I think that is an excellent compromise between my patch and
> Karl's suggestions. I'll work up the patch and send it in when I get
> a chance.

- Julian

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 12:40:57 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.