2011/4/16 Branko Čibej <br...@e-reka.si>: > On 16.04.2011 16:14, Johan Corveleyn wrote: >> Do I have to worry about differences between on-disk casing and wc-db >> casing of a path? Is that possible? I guess it is by using non-svn >> commands, but I bet that's an invalid state of the wc (I know that in >> 1.6, if you run into this, svn gets all confused (marking the file it >> has in metadata as deleted, and your on-disk file as unversioned)). >> That's definitely out of scope for the change I'm trying to make. > > "Valid state" is kinda fuzzy, and since some tools (still) insist on > changing file case every which way, this case can realistically be > expected to happen every once in a while. But certainly more than just > rename are affected by it, so I guess it's not realistic to try to deal > with the problem in your patch. > > The most famousest case where this can happen is if you try to check out > "Foo" and "fOO" in the same directory on a case-insensitive file system. > Our answer to that has been, "don't do that"; and it would take very > significant surgery in the client and WC libraries to make it work. I'm > unaware of any version control system that handles such cases correctly. > > By the way, does your patch deal with the case where an "svn update" > results in a case-only rename?
AFAIK, that already works correctly (at least it did in 1.5 and 1.6 - we regularly had that situation at work - no problem, the filename is changed to the correct casing during "update"). The only problem I'm trying to address is that "svn move" still blocks a case-only rename on Windows at the command-line / client layers, although WC-NG can now handle it. WC-1 couldn't handle it in the working copy, but WC-NG can. As explained by Bert in the last comment of issue #3702: "svn ren TODO todoQ; svn ren todoQ todo" now works with WC-NG, while it didn't work in the past. But "svn ren TODO todo" is still blocked, because it's internally converted to "svn ren TODO TODO" (both paths converted to on-disk casing). -- Johan
