View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000533 | Subversion for OS/2 & eCS | Bug | public | 2012-04-15 22:45 | 2012-05-25 00:29 |
| Reporter | xhajt03 | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | I386 | OS | eCS | OS Version | 1.0 (last FP) |
| Summary | 0000533: Handling of case in directory names in client | ||||
| Description | Paths 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. | ||||
| Tags | No tags attached. | ||||
|
|
Sorry, I should have mentioned that it is related to the SVN client version 1.7.4 built on the 12th of March 2012. |
|
|
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 |
|
|
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? |
