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

Re: svn commit: r10133 - in trunk/subversion: include libsvn_subr tests/clients/cmdline tests/libsvn_subr

From: Josh Pieper <jjp_at_pobox.com>
Date: 2004-07-05 01:06:32 CEST

Branko ??ibej wrote:
> Josh Pieper wrote:
>
> >Ben Reser wrote:
> >
> >
> >>On Sun, Jul 04, 2004 at 11:57:24AM -0400, Josh Pieper wrote:
> >>
> >>
> >>>Ok, in IRC ghudson proposed:
> >>>
> >>><ghudson> Well, I'd agree with your initial judgement that we
> >>>shouldn't be collapsing .. segments, and then if we changed the
> >>>apr_filepath_merge() call in opt.c to an svn_path_canonicalize, we'd
> >>>fix the case I mentioned was broken.
> >>>
> >>>I don't believe we considered the symlink case when breser and I
> >>>initially talked on IRC about supporting collapsing "/../" elements.
> >>>Does anyone have objections to just removing the ".." collapsing
> >>>support from svn_path_canonicalize? That would also resolve the issue
> >>>of implementing svn_path_canonicalize in terms of apr_filepath_merge.
> >>>
> >>>
> >>No we sure didn't. But if we remove the colapsing of .. in paths we
> >>still need it in URLs. See the comment by Klaus Rennecke about the
> >>weirdness that occurs with URLS with /../ in them.
> >>
> >>
> >
> >file:/// URLs would have to be special cased then to leave the ".."
> >path elements in since a portion is directly translated to a
> >filesystem path.
> >
> >
> No they do not. They're still URLs, not paths.

I don't understand. Are you saying that some portions of file:// URLs
are not given directly to the filesystem to resolve? Or that we can
safely collapse "/../" paths from them? Or something else?

-Josh

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 5 01:08:31 2004

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.