Hi Lieven,
Hopefully on the way through svn_path_is_ancestor() can be made to work
with a little knowledge of the case sensitivity of the various parts of
the url and path names. I came across this earlier with a segmentation
fault during an svn copy operation. see:
http://svn.haxx.se/dev/archive-2008-08/0667.shtml
Just to be a bit nicer to the user when typing urls, if c: - C: and
\\server\share - \\SERVER\SHARE could be treated as identical because they
always are. The file names can not be in general as people can use Samba,
nfs on Windows etc.
This also applies to server names, which are case insensitive, but are
not in
subversion ( svn copy svn://svn.Collab.net/repos/path/filename ./filename
gives an error on a working copy checked out from svn.collab.net )
What do you think?
Alan Wood
On 21 Sep 2008 at 0:30, Lieven Govaerts wrote:
> 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
---------------------------------------------------------------------
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 05:09:01 CEST