Re: How to fix issue #4023 (on Windows, 'svn rm missingItem' deletes the unversioned 'MissingItem' from disk)?

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.

> 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.

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?

> 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."

> 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!

>> 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)?

- Julian
Received on 2012-01-23 17:35:18 CET