On Mon, Jan 23, 2012 at 5:34 PM, Julian Foad <julianf...@btopenworld.com> wrote:
> Johan Corveleyn wrote:
>
>> Julian Foad 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'? [...]
>>
>> The case here is:
>> [abbreviated]
>> C:\test>svn rm fILE.eXT
>> C:\test>echo bla > file.ext
>> C:\test>svn st
>> ? file.ext
>> D fILE.eXT
>
> If Subversion is supposed to be behaving as a Windows app, this status output
> is wrong. A Windows app should recognize that the DB entry 'fILE.eXT' refers
> to the file 'file.ext'. Therefore the status output should show just one
> line ("D file.ext"), because we don't give any special indication if a
> schedule-delete file is unexpectedly present on disk.
I disagree. There is a difference between working copy metadata (which
is a database), and the stuff that's on disk. AFAIU, status shows a
combination of both. Subversion has always, on Windows, shown this as
two different items (well, I say 'always', but I don't really know
that of course. In any case since 1.5, which is the oldest version
I've ever used).
I think showing these as two different lines is very sane and natural
behavior, because they *are* two different items. I think most Windows
SVN users understand this distinction.
>> 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 [...].
>
> Although the WC DB can *represent* two case-clashing items, Subversion will
> not *work* properly if you do that, in general. As far as I know, just one
> special case of this has been made to work: the case-only rename.
No. WC-NG has made it possible to represent both items, also on
Windows. This has immediately made it possible for non-commandline
clients to work properly with them on Windows (there was no real
problem in the client and wc layers).
Fixing issue #3865 simply made that possible for the commandline client too.
> But now you are talking about a different case. In your example here, there
> are not two different variations of the name in the WC.DB, there is just
> one. So what rules apply here?
Yeah, sorry for the confusion. My first example was the simplest
possible: a single deleted (or 'missing') item in wc.db, with an
unversioned case-clashing file in the way. But with two items in
wc.db, the same rules apply, when you're specifying something on the
commandline:
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.
This is exactly what's needed for executing and committing a case-only
rename on Windows:
$ svn mv FOO foo # needs #3702
$ svn ci FOO foo # needs #3865
But, for that last commit, the 'svn ci FOO Foo' would work as well
(which is maybe a bit weird, but hey, this is how most Windows apps
work :-)).
>> 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.
>
> By saying that, I think you're implying that there is a rule:
>
> "Subversion will only recognize a file on disk in this situation if it's
> case-identical to the DB entry."
I had to think about that sentence a bit :-). But I think you're
right. And that rule is correct too: svn has always (AFAIK) worked
this way: a file differing in case from svn's DB entry has always been
seen as a different file. Just try this with any old svn version on
Windows: if you change case (on the filesystem) of a versioned file,
'svn status' will now show two items: one missing (the DB one) and one
unversioned (the new casing).
I think this is good behavior, but I can't really argue much more
about the why and how, ... that's from way before my time with SVN
:-).
>> 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
>>
>>> 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?
>
> It's no good asking me -- I'm asking you to tell me the rules!
Obviously I was not asking you. I was merely pointing out that SVN
should somehow be able to understand what the user means. I think the
"case-exact match refers to DB item" rule is a good way to accomplish
that.
>>> What filename casing rules do we want Subversion to follow on Windows?
>>> [...]
>>
>> I'd say we pretty much decided on that when we fixed #3865 [...]:
>>
>> 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.
>
> That's not a sufficient set of rules. I think you mean this is the rule for
> interpreting a filename given on the command line. What is the rule for when
> Subversion interprets (uses) a filename that it has found internally (from
> WC.DB? from the svn server)?
I have only (with #3865 and #3702) changed the rules for the command
line client.
I don't know what the rules are in other places, you'd have to ask
other people.
But I see where you're coming from, I think. With issue #4023 we're
scratching the surface of how svn should handle these ambiguities
internally (in the wc layer, at least).
I'd like to note though that #4023 is also potentially an issue for
svn < 1.7 (pre-wcng). At least if you're thinking about
non-commandline usage. As of #3865, one can now also run into this
situation with the commandline client, because you're now able to
successfully invoke 'svn rm foo' while foo is missing and unversioned
FOO is in the way. But if you're talking directly to the client layer,
it's easy to pass 'foo', and the current code will then happily remove
foo from wc.db, and FOO from disk. There is no need for any of my
"fixes" to do that.
--
Johan
