[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: Bert Huijben <bert_at_qqmail.nl>
Date: Fri, 12 Nov 2010 10:55:08 +0100

> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.name]
> Sent: donderdag 11 november 2010 22:28
> To: dev_at_subversion.apache.org
> Subject: Which family of path/dirent/uri/relpath functions to use for
> svn_lock_t->path?
>
> set_lock() subversion/libsvn_fs_fs/lock.c uses svn_dirent_* to interact
> with this_path, which is initialized with an svn_lock_t->path.
>
> Should that function be using svn_relpath_* or svn_uri_* instead?

That depends on the path kind stored in this value.

Is it a path in the form '/trunk/some/path' then svn_relpath_X will assert
on an invalid relative path.

svn_uri_* is currently the only non-deprecated set of path functions that
allows this deprecated format.

@julianf: This is why svn_uri handles urls and other paths differently.

We currently have:
* dirent: local paths (architecture specific)
* relpath: Only paths in the form 'some' or 'some/subdir' are valid. '/qq'
and 'some/./dir' are not.
* uri: All other paths.

Uri should actually be '<schema>://<schema-base>/<path>', but when we
started working on these apis we deprecated svn_path and had only dirent and
uri functions to replace them.

I think we should:
* either introduce a svn_fspath_*() set of functions for '/style/paths'.
* or deprecate the entire '/style/path' notation in our internal handling.
(We can replace them with relpaths by just removing the initial '/')

(An temporary third option would be to introduce a svn_fspath__ internal set
of functions, to keep svn_uri_ clean)

        Bert
Received on 2010-11-12 10:55:49 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.