On 24.01.2012 15:15, Philip Martin wrote:
> Daniel Shahaf <danielsh_at_elego.de> writes:
>
>>> 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.
>> But normal windows programs don't have the concept of "one on disk and
>> one in wc.db". And I imagine we want to have some syntax to refer to the
>> latter.
> What I meant was names rather than files. So one of foo/FOO/Foo in
> wc.db, another on disk and another on the command line.
You are complicating the issue far more than necessary. Assuming the
owner of the repository knows that there are going to be windows
clients, the case you describe is not going to happen in the first
place. Even Unix-centric repositories will not likely or often have
names in the same directory that differ only in case.
It's far more likely that there's foo in the wc.db, FOO on dist, and the
user types Foo. The solution to this most common case is blindingly
obvioius, but quite hard to do right because one can't really do
case-insensitive queries into the wc.db, and certainly not with the same
case folding rules that the filesystem uses (yes, especially with NTFS
which most everybody uses these days, there's no guarantee that the FS
will case-fold in the same way as the currently active locale).
The reasonable solution would be:
* if the name exists in the wc.db but not on disk, try to
case-normalize to the on-disk form (and, possibly, case-rename to
the wc.db form on the fly)
* if the name does /not/ exist in wc.db, still try to case-normalize
to the on-disk form, then scan the directory info in wc.db and see
if any name in there can be normalized to the same on-disk form. If
there's exactly one, use that and proceed as above. If there are
more than one, cry for help.
-- Brane
Received on 2012-01-25 09:53:35 CET