Re: How to fix issue #4023 (on Windows, 'svn rm missingItem' deletes the unversioned 'MissingItem' from disk)?
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 23 Jan 2012 16:34:40 +0000 (GMT)
Johan Corveleyn wrote:
> Julian Foad wrote:
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
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
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?
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?
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)?
This is an archived mail posted to the Subversion Dev mailing list.