On Tue, Jan 24, 2012 at 2:45 PM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Johan Corveleyn <jcorvel_at_gmail.com> writes:
>
>> On Mon, Jan 23, 2012 at 4:28 PM, Philip Martin
>> <philip.martin_at_wandisco.com> wrote:
>>> Is that sufficient? Given three files "foo", "FOO" and "Foo", one in
>>> wc.db, one on disk and one on the command line, is that the same file?
>>> Add another "fOO" to the database. It's now ambiguous?
>>
>> No, it's not:
>
> Is that answering the first question "same file?" or the second question
> "ambiguous?" or both?
Sorry. That was 'no, it's not ambiguous'.
>>
>> - Both fOO and foo exist in wc.db.
>> - FOO is on disk.
>> - I invoke 'svn <subcommand> Foo':
>> 1. Is there a case-exact match in wc.db? No
>> 2. Ok, then apply truepath-ing: so the user is meaning FOO.
>>
>> But the user can still do useful things to fOO and foo, if he gives
>> the exact correct casing.
>
> What about the first bit.
>
> Given three files "foo", "FOO" and "Foo", one in
> wc.db, one on disk and one on the command line, is that the same file?
>
> My understanding is that a Windows user expects those to be the same
> file. So "svn st FOO", "svn st foo" and "svn st Foo" all refer to the
> file in wc.db and the file on disk even though the cases don't match.
I'm a Windows user. I know SVN has its own internal database. I do not
expect svn to act like these are the same if they differ in case.
Again, this is not something new in 1.7, it has *always* been that
way. And that's a *good* thing. Otherwise, there would not be the
slightest chance to have a case-only rename on Windows, which is
pretty bad. Users need this all the time.
- "svn st FOO": shows only status of FOO, not of foo. (on disk file)
- "svn st foo": shows only status of foo, not FOO. (case-exact match in wc.db)
- "svn st Foo": shows only status of FOO, not of foo. (no case-exact
match anywhere, search for truepath-conversion, find FOO)
No problem. This is what I expect.
--
Johan
Received on 2012-01-24 15:09:38 CET