On Mon, Jan 23, 2012 at 4:05 PM, Philip Martin <philip.mar...@wandisco.com> wrote: > Julian Foad <julianf...@btopenworld.com> writes: > >> We haven't chosen to behave like a case-insensitive Windows app, it >> seems, and obviously(?) we can't be fully case-sensitive when the >> underlying Windows APIs are not. The rules we choose must govern how >> we fixed all the case-related issues (#3702, #3865, #4023 at least). >> We can't classify this issue as a "bug" and "fix" it until we define >> what behaviour we want. > > I agree it needs to be properly defined. There are so many questions > about the behaviour, for example: > > Suppose wc.db contains "foo" and "FOO" and the disk has "FOO". If the > user types "foo" can that refer to "FOO" on disk?
No, it refers to "foo". > Suppose wc.db contains "foo" and "FOO" and the disk has "Foo". If the > user types "foo" can that refer to "Foo" on disk? No, it refers to "foo". > Suppose wc.db contains "foo" with status=not-present and "FOO" and the > disk has "FOO". If the user types "foo" does that refer to "FOO" on > disk? No, it refers to "foo". The only criterion is: is there a case-exact match in wc.db somewhere. Otherwise, go on and case-normalize to what's on disk. > Are the rules the same for all operations such as "rm", "up", "diff"? I hope so :-). That's the intention. > Will a Windows user know what to expect? Will Windows users all expect > the same thing? I'd say yes, but I'm only one user of course :-). Not much of a metric ... Keep in mind that a lot of these issues are related to commandline usage of svn. GUI's will have to solve these problems in their own way (whichever way they prefer to make it clear to the user that they can also "select" and do things with an item from wc.db that's case-clashing with another on-disk item). -- Johan
