On Mon, Jan 23, 2012 at 3:24 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Johan Corveleyn wrote:
>> Ok, but in the svn working copy, even on Windows, we can have a valid
>> fILE.eXT in wc.db, while there is an unrelated file.ext present on the
>> filesystem. We should be able to do useful things with the svn item
>> fILE.eXT in one way or another, without harming file.ext.
>
> Excuse me for jumping in here, but why do you say 'file.ext' is 'unrelated'? Normally on Windows, if an application or user asks about 'fILE.eXT' and there is a 'file.ext' on disk, the user expects the application to open the existing 'file.ext'. In other words, that file on disk has *the same name* as the file I'm talking about, by definition, because the definition of file name handling on Windows is case-insensitive.
The case here is:
[[[
C:\test>dir /B
fILE.eXT # suppose this is a versioned file
C:\test>svn rm fILE.eXT
D fILE.eXT
C:\test>dir /B
C:\test>echo bla > file.ext
C:\test>dir /B
file.ext
C:\test>svn st
? file.ext
D fILE.eXT
]]]
On the Windows filesystem, there is no ambiguity: there is only a
'file.ext', and when any application or Windows API wants to do
something to FiLe.ExT, they will get file.ext. We're case-insensitive
after all.
However, the problem is that the subversion working copy can represent
more: it can represent items that are no longer present on disk. It
can also represent two (or more) case-clashing items in its database,
even if only one of them can be present as a file on disk (note that
this is new since WCNG, in WC-1 you couldn't have both foo and FOO in
the working copy database together).
So in svn-wc's universe there is an item that's not represented on
disk, but is 'case-shadowed' (for lack of a better term) by some other
file on disk. How can we tell 'svn' to do something with fILE.eXT now?
That's the whole problem, and it's an essential piece of the
"case-only rename" puzzle on Windows. Without this, there is no way we
can do 'svn mv foo FOO' on Windows, which is pretty painful because
Windows itself has no problem at all with executing 'move foo FOO'
(though it is case-insensitive, it is also case-preserving, so casing
does matter). (of course, Windows doesn't have to keep track of a
deleted item 'foo', after it's been renamed, like svn does, so ...).
> I know that Subversion doesn't strictly have to behave like a standard Windows app. So...
Well, it does a pretty good job of behaving like a standard Windows
app. But there is simply ambiguity here. When you type 'svn commit
fILE.eXT', do you mean the item on disk, file.ext, like any other
Windows app would assume. Or do you mean the item fILE.eXT that's
present in svn's database?
> What filename casing rules do we want Subversion to follow on Windows?
>
> 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'd say we pretty much decided on that when we fixed #3865 (maybe
there are some relevant mail-threads about this, no time to look them
up now, sorry --- most of this was implemented while we were in Berlin
last year):
If there is no case-exact match on disk, but there is a case-exact match
in wc.db, assume the user refers to the latter. Otherwise case-normalize
like any other Windows app.
>>> We can never 100% emulate a case sensitive filesytem on a case
>>> insensitive one.
>>
>> Heh. But we can still try to emulate it as good as possible :-).
>
> But seriously?
No, I didn't mean emulating a case-sensitive filesystem of course. But
we still need to be able to represent (and be able to address) the
items that can exist in a working copy database.
--
Johan
Received on 2012-01-23 16:11:40 CET