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

Re: Which family of path/dirent/uri/relpath functions to use for svn_lock_t->path?

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Fri, 12 Nov 2010 17:41:56 +0000

Peter Samuelson wrote:
> [Julian Foad]
> > Proposal for switching to a dedicated "fs path" API:
> >
> > Step 1: Introduce a new API for FS paths, as a thin layer that maps to
> > existing path APIs. It must assert that the fspath arguments and fspath
> > return values begin with '/'. Initially it should map directly to
> > svn_uri_*, so that it can be seen to be a direct replacement.
> So do these or do these not involve doing URI escaping? %20 for space,
> etc.

No escaping involved here - these are not URLs and these are not
relative-URLs and so do not have any escaping inside them. When we make
a URL from a base URL and a repo-relpath, *then* we will escape it.

I believe, but haven't checked recently, that the present set of
svn_uri_* functions doesn't touch or care about percent-escaping when
handling these paths. Because we have forced them to handle this case,
they don't assert that their arguments are canonical. After we make
this transition, then the svn_uri_* functions should be able (from a
correctness point of view) to assert that their 'URI' inputs and outputs
are canonical.

> By calling them 'fs paths', the assumption is that these are in
> UTF-8, and there is no marshalling / escaping to even think about,
> except when converting it to or from a URI or dirent. Is that the
> intent?


> > Bikeshed: svn_fspath__* or svn_fs__path_* or something else?
> svn_fspath__ seems better to me. svn_fs__path_ sounds like this is all
> internal to libsvn_fs, whereas I understand you want this in
> libsvn_subr for layers to use that are _not_ specifically talking about
> svn_fs internals.

Correct, so yes, I agree.

- Julian
Received on 2010-11-12 18:42:38 CET

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.