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

Re: svnadmin dump/verify/load uses svn_path_join

From: Lieven Govaerts <svnlgo_at_mobsol.be>
Date: 2007-03-13 22:45:39 CET

D.J. Heap wrote:
>> Based on your report I'm worried a bit that there are more situations
>> like this,
>> were path functions for internal paths were modified to work for
>> Windows paths.
>> I'll see what I can find, tonight.
> Thanks for looking at it!

I did a quick scan through the code and the conclusion is very simple:
on Windows, trunk svn can't handle paths like 'c:hi' stored in the
repository. Meaning, direct operations on those urls will fail. Checking
those out will also fail obviously, so it's not that this is a common
situation, but still.

Your specific issue was fixed easily by reverting svn_path_join and
svn_path_join_many to their original (unix only) implementation. But
then I tried 'svn "ls file:///c:/temp/repos/c:hi"'. Result:
..\..\..\subversion\libsvn_client\delete.c:184: (apr_err=160013)
svn: URL 'hi' does not exist. The problem here is in svn_path_split,
which uses svn_path_dirname and svn_path_basename. All these functions
(10 in total) support Windows paths right now.

So, the scope of the problem we're facing is that the word 'path' in the
path functions can mean four things:
1.native directory/file names, (C:\temp) etc.
2. canonicalized native directory/file names (C:/temp)
3. urls (file:///c:/temp/repos/c:hi)
4. repos-internal directory/file names (/c:hi/A/B/C)

When adding windows path support to the path functions I didn't take
paths of type four into account, hence the situation you reported.

Problem is, not all path functions can handle all those four cases at
the same time.
Example: svn_path_join("/", "c:hi") in the above four cases returns:
1+2: c:hi because c:hi is an absolute path on Windows
3: n/a
4: /c:hi

Now svn_path_join is used over 350 times in the Subversion code, in all
of the 4 cases. The same goes for svn_path_dirname, svn_path_basename etc.

To be honest, I don't see many other options than to revert the whole
windows path thing and start from scratch on a feature branch. We'd have
to work out all different usage patterns of the path functions, create
new path functions for native, url, internal paths, and start using them
throughout the code. To test all that a new test case has to be created
to test all possible svn manipulations on 'c:hi' folders.

What do you think?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 13 22:45:52 2007

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.