You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Blair Zajac <bl...@orcaware.com> on 2007/10/16 22:13:51 UTC
svn_opt_parse_path and canonical paths
I need a version of svn_opt_parse_path() that doesn't canonicalize it's
arguments for relative externals (the scheme relative //hostname/path/to/repos
has it's // collapsed to / so it becomes a server root relative URL).
In the docstring for svn_opt_parse_path() it makes no mention that it accepts
non-canonicalized paths and returns canonicalized paths, but looking at its
implementation, it does this.
I'm guessing there's a lot of code that assumes that you can use
svn_opt_parse_path() without calling svn_path_canonicalize() calls from its
implementation.
If we ever want to support relative URLs on the command line, I'm guessing that
we'll need to change svn_opt_parse_path() to not canonicalize it.
So I guess I'm looking at some doing some code duplication or I can go through
all callers of svn_opt_parse_path() and check that they do some call to
svn_path_canonicalize() afterwards.
BTW, it looks like svn_path_local_style() has always canonicalized its
arguments, so anybody mind adding it to the list of functions that are safe to
use at the top of svn_path.h with uncanonicalized form:
* Nearly all the @c svn_path_xxx functions expect paths passed into
* them to be in canonical form as defined by the Subversion path
* library itself. The only functions which do *not* have such
* expectations are:
*
* - @c svn_path_canonicalize()
* - @c svn_path_is_canonical()
* - @c svn_path_internal_style()
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_opt_parse_path and canonical paths
Posted by Blair Zajac <bl...@orcaware.com>.
Blair Zajac wrote:
> C. Michael Pilato wrote:
>> Blair Zajac wrote:
>>> I need a version of svn_opt_parse_path() that doesn't canonicalize it's
>>> arguments for relative externals (the scheme relative
>>> //hostname/path/to/repos has it's // collapsed to / so it becomes a
>>> server root relative URL).
>>
>> Could you simply test for "//" before parsing the path, then re-add the
>> extra forward slash after parsing if the prior test returned true?
>
> Yes, but svn_opt_parse_path() always returns canonicalized paths, even
> though its documentation in svn_path.h doesn't say so.
>
> Do you think most users of svn_opt_parse_path() know they can pass in
> uncanonicalized and always get back canonicalized paths? If not, then I
> can relax the code.
>
> I may have to audit all uses of svn_opt_parse_path() and ensure that the
> result is passed through one of the canonicalization functions.
Committed in r27236.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_opt_parse_path and canonical paths
Posted by Blair Zajac <bl...@orcaware.com>.
Troy Curtis Jr wrote:
> On 10/16/07, Blair Zajac <bl...@orcaware.com> wrote:
>> C. Michael Pilato wrote:
>>> Blair Zajac wrote:
>>>> I need a version of svn_opt_parse_path() that doesn't canonicalize it's
>>>> arguments for relative externals (the scheme relative
>>>> //hostname/path/to/repos has it's // collapsed to / so it becomes a
>>>> server root relative URL).
>>> Could you simply test for "//" before parsing the path, then re-add the
>>> extra forward slash after parsing if the prior test returned true?
>> Yes, but svn_opt_parse_path() always returns canonicalized paths, even though
>> its documentation in svn_path.h doesn't say so.
>>
>> Do you think most users of svn_opt_parse_path() know they can pass in
>> uncanonicalized and always get back canonicalized paths? If not, then I can
>> relax the code.
>>
>> I may have to audit all uses of svn_opt_parse_path() and ensure that the result
>> is passed through one of the canonicalization functions.
>>
>> Blair
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: dev-help@subversion.tigris.org
>>
>>
>
> Earlier you said "If we ever want to support relative URLs", do you
> know if there is anyone trying to implement that? I'm very interested
> in having that capability and thought I might take a look at working
> on it.
No, I'm not aware of anybody working on that currently.
Regards,
Blair
--
Blair Zajac, Ph.D.
<bl...@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_opt_parse_path and canonical paths
Posted by Troy Curtis Jr <tr...@gmail.com>.
On 10/16/07, Blair Zajac <bl...@orcaware.com> wrote:
> C. Michael Pilato wrote:
> > Blair Zajac wrote:
> >> I need a version of svn_opt_parse_path() that doesn't canonicalize it's
> >> arguments for relative externals (the scheme relative
> >> //hostname/path/to/repos has it's // collapsed to / so it becomes a
> >> server root relative URL).
> >
> > Could you simply test for "//" before parsing the path, then re-add the
> > extra forward slash after parsing if the prior test returned true?
>
> Yes, but svn_opt_parse_path() always returns canonicalized paths, even though
> its documentation in svn_path.h doesn't say so.
>
> Do you think most users of svn_opt_parse_path() know they can pass in
> uncanonicalized and always get back canonicalized paths? If not, then I can
> relax the code.
>
> I may have to audit all uses of svn_opt_parse_path() and ensure that the result
> is passed through one of the canonicalization functions.
>
> Blair
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Earlier you said "If we ever want to support relative URLs", do you
know if there is anyone trying to implement that? I'm very interested
in having that capability and thought I might take a look at working
on it.
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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_opt_parse_path and canonical paths
Posted by Blair Zajac <bl...@orcaware.com>.
C. Michael Pilato wrote:
> Blair Zajac wrote:
>> I need a version of svn_opt_parse_path() that doesn't canonicalize it's
>> arguments for relative externals (the scheme relative
>> //hostname/path/to/repos has it's // collapsed to / so it becomes a
>> server root relative URL).
>
> Could you simply test for "//" before parsing the path, then re-add the
> extra forward slash after parsing if the prior test returned true?
Yes, but svn_opt_parse_path() always returns canonicalized paths, even though
its documentation in svn_path.h doesn't say so.
Do you think most users of svn_opt_parse_path() know they can pass in
uncanonicalized and always get back canonicalized paths? If not, then I can
relax the code.
I may have to audit all uses of svn_opt_parse_path() and ensure that the result
is passed through one of the canonicalization functions.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_opt_parse_path and canonical paths
Posted by "C. Michael Pilato" <cm...@collab.net>.
Blair Zajac wrote:
> I need a version of svn_opt_parse_path() that doesn't canonicalize it's
> arguments for relative externals (the scheme relative
> //hostname/path/to/repos has it's // collapsed to / so it becomes a
> server root relative URL).
Could you simply test for "//" before parsing the path, then re-add the
extra forward slash after parsing if the prior test returned true?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand