View Issue Details

IDProjectCategoryView StatusLast Update
0000533Subversion for OS/2 & eCSBugpublic2012-05-25 09:59
Reporterxhajt03 Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status newResolutionopen 
PlatformI386OSeCSOS Version1.0 (last FP)
Summary0000533: Handling of case in directory names in client
DescriptionPaths on the local drive should be compared to those stored in the checkout structure in case insensitive manner.

Let's imagine having a directory 'dir' in a root of a SVN checkout. If you change directory to 'DIR' e.g. in CMD.EXE, OS/2 remembers 'DIR' as the current directory. Now, trying to invoke any svn operations from that directory fails because 'DIR' does not exist in the checkout structure encoded in ../.svn (probably wc.db with the newly used SQLite base storage?). If I go to the same directory by changing directory to 'dir' (as stored on the disk), it works correctly.
TagsNo tags attached.

Activities

xhajt03

2012-04-16 08:18

reporter   ~0002238

Sorry, I should have mentioned that it is related to the SVN client version 1.7.4 built on the 12th of March 2012.

psmedley

2012-04-29 19:17

administrator   ~0002258

This one might be a problem... Seems this is an issue on mac/windows too

See http://stackoverflow.com/questions/595081/can-svn-handle-case-sensitivity-issues

xhajt03

2012-05-03 22:28

reporter   ~0002259

No, this shouldn't be the same problem. The request mentioned above basically asks for the SVN server to be configured as case insensitive (regardless of the clients). This could obviously not be solved by your port, but I don't need that fortunately.

The thing I need (case insensitive matching on the client side when running on a case insensitive platform/filesystem - i.e. in particular for the OS/2 / eCS port here) worked well in previous SVN versions.

The probable reason why it stopped working with 1.7.x is because of the different way how SVN stores the file hierarchy. Previously (up to SVN 1.6.x), the directory .svn existed in each and every directory of any checkout and the file 'entries' stored in .svn contained only files in that directory (local). Since 1.7, all the metadata for a particular checkout are stored in a single .svn directory at the root level of that checkout, file 'entries' apparently contains only version number for the SVN metadata structure and the files with the path relative to the checkout root are stored in a SQLite database file wc.db. I assume that the solution for my problem would be to switch searching the SQLite database to a case insensitive manner. Don't ask me where it is in the sources or how to change it though. ;-)

The trouble which may make OS/2 / eCS different from the Windows or Mac OS X case is the fact that OS/2 is case insensitive internally (unlike Windows or Mac OS X which support case insensitive file systems but are case sensitive at the kernel level). If you open CMD.EXE, create directory 'test' ('mkdir test') and switch to the newly created directory using 'cd TEST', OS/2 stores internally (for the particular session) that your current directory (for the particular current drive) is 'TEST' and it will show it that way in CMD.EXE and also return it that way in the respective OS/2 API function (DosQueryCurrentDir). If you do the same under MS Windows (WinXP tested here), MS Windows store the real name as the current working directory, not the one used when changing to it. I don't know whether there is any way to find out the real pathname (including the correct case). If something like case insensitive searching is not possible in SQLite, an alternative may be not to use the results of DosQueryCurrentDir (or the respective libc wrapper around it) directly but rather always translate it to the real path first. If OS/2 doesn't provide any support for querying the real case directly (which is well possible), one can always traverse the path from the root and check the real case using DosFindFirst for the next path element. Hope that this helps...

BTW, I've received no notification about your note although I use the monitoring function of Mantis - any idea what got wrong here?

Issue History

Date Modified Username Field Change
2012-04-16 08:15 xhajt03 New Issue
2012-04-16 08:18 xhajt03 Note Added: 0002238
2012-04-29 19:17 psmedley Note Added: 0002258
2012-05-03 22:28 xhajt03 Note Added: 0002259