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

Re: [RFC] Canonical Paths

From: Justin Erenkrantz <jerenkrantz_at_apache.org>
Date: 2002-08-28 22:19:20 CEST

On Wed, Aug 28, 2002 at 09:12:46PM +0100, Philip Martin wrote:
> 1. The Subversion libraries only handle canonical paths, and all the
> functions should passed canonical paths. The only exceptions to
> this rule are svn_path_internal_style, svn_path_canonicalize and
> svn_path_canonicalize_nts, which obviously can accept non-canonical
> paths.


> 2. The application is responsible for canonicalizing all user input
> paths before passing them to the Subversion.

+1. (I wish there were a way to enforce this in code.)

> 3. The canonical form for the path representing the current directory
> could be either "." or "". Currently the path library is not
> consistent. We should pick one, and then we do not need to handle
> the other. APR is know to have some problems using "", so "."
> would be the one I would choose.

Yeah, "." is the right answer if you ask me.

> 4. Functions like svn_path_split, svn_path_remove_component, etc
> should only return canonical paths.

And, I think that's been the biggest problem so far - they don't.

> 5. In some places the path library handles NULL paths. This is
> unnecessary, as all inputs should be canonical, and so should be
> removed (fixing any breakage that results).

What is the interpretation of a NULL path?

> One question: svn_path_internal_style, which converts from native
> separators to canonical separators, doesn't seem to be used. Should
> the application pass all user input paths through this function?

I think so. (should it also UTF-8 encode/decode it?) -- justin

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 28 22:19:51 2002

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.