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

RFC: replace svn_path functions with svn_dirent and svn_uri.

From: Lieven Govaerts <svnlgo_at_mobsol.be>
Date: Sun, 21 Sep 2008 00:30:57 +0200

This mail is meant as a summary of the earlier discussions concerning
correct handling of Windows directories and as a proposal to go forward
and get this over with for once and for all. This proposal will
implement task #2028 in the issue tracker.

Problem:
Subversion doesn't support the Windows directory syntax correctly,
resulting in failing commands, incorrect console output or segmentation
faults.

Some examples of this problems are logged in our issue tracker and mail
archive:
http://subversion.tigris.org/issues/show_bug.cgi?id=2556
http://subversion.tigris.org/issues/show_bug.cgi?id=1711
http://svn.haxx.se/dev/archive-2008-08/0088.shtml
http://svn.haxx.se/dev/archive-2007-03/0385.shtml

Analysis (mostly copied from the last url above):
Many of the svn_path* functions don't handle Windows directories
correctly. More specifically absolute paths like E:\foo, relative paths
like E:foo and UNC paths like \\server\share.

It seems the svn_path functions are supposed to handle four different
types of paths:
1. Native directory/file names: C:\temp, /foo/bar etc.
2. Canonicalized native directory/file names: C:/temp, //server/share/
3. URLs: file:///c:/temp/repos/c:hi, http://server/repos
4. URIs, repos-internal directory/file names: foo/bar, c:hi/A/B/C etc.

Type 1 is converted to type 2 at the API boundaries.
Type 3 and 4 can be considered as the same as their syntax is identical
on all platforms.

In some cases a svn_path function tries to determine whether it's
working with a directory/filename (dirent) or url/uri. Problem is, this
doesn't work on Windows.

<Example>
svn_path_join("/", "c:hi") should return for each of the above four cases:
1+2: c:hi because c:hi is an absolute path on Windows
3: n/a
4: /c:hi
There's no way svn_path_join can decide on returning 'c:hi' or '/c:hi'
on Windows, unless it knows whether the two paths are dirents or uris.
</Example>

Proposal:
As indicated by the example above we can't rely on an svn_path function
to assess whether it's working with directories or uris. Which leaves us
no option than to make the callers take this decision.

So, we:
1. For each of the svn_path functions, add an svn_dirent equivalent that
supports Windows directory syntax (on Windows).
2. For each of the svn_path functions, add an svn_uri equivalent when
needed.
3. Expand the set of unit tests to make sure the new functions work
correctly on both Windows and POSIX platforms.
4. Expand the set of acceptance tests to handle the Windows specific issues.
5. Dig through the code and replace all svn_path* calls with either
svn_dirent* or svn_uri*.
6. Deprecate all svn_path functions.

Implementation notes:
* I'd add files svn_dirent_uri.h and svn_dirent_uri.c with the new
functions.
* most of the svn_dirent functions and unit tests were already written
some time ago, but reverted. They can be found in
trunk/subversion/libsvn_subr/path.c_at_23906.
* naive implementation will result in lots of duplicated code, we should
use private implementation functions were possible.
* the branch windows_dirents was created to implement this proposal.
* Steps 5 and 6 can be done incrementally, function per function. In any
case, the svn_path functions have to kept until svn 2.0.

With the new working copy implemetation getting along now is probably
the best time to make this change. If people agree with the above
proposal, I'll start with bringing back the old code to HEAD. At this
time I can't make any real promises on my availability though, so any
help (especially for updating all callers) is appreciated.

Lieven.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-21 00:31:13 CEST

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.