[SVN-4023] on case-insensitive filesystems (usually Windows or OSX), 'svn rm' incorrectly deletes on-disk file if it is case-clashing with intended (missing) target

• Type: Bug
• Status: Open
• Priority: Critical
• Resolution: Unresolved
• Affects Version/s: ---
• Fix Version/s: 1.10-consider
• Component/s: libsvn_wc

Environment

Windows XP

• Assignee: Unassigned
• Reporter: Johan Corveleyn
• Created: 25/Sep/11 20:55
• Updated: 19/Feb/15 14:53

Description

As reported by Marc Strapetz in this email thread: 

    http://svn.haxx.se/dev/archive-2011-09/0262.shtml

'svn rm' on Windows incorrectly deletes the wrong file from disk when that file
is case-clashing with the actual intended target (which is missing). This can
result in the loss of an uncommitted file.

An example (with a case-change done outside of svn; another example would be
with the second file being an unversioned file):
[[[
C:\foo>move bar BAR
### move is done outside of svn's knowledge

C:\foo>svn st
!       bar
?       BAR
### this is normal

C:\foo>svn add BAR
A         BAR

C:\foo>svn st
!       bar
A       BAR
### still normal

C:\foo>svn rm bar
D         bar

C:\foo>svn st
!       BAR
D       bar
### this is wrong 
]]]

The last 'svn rm bar' removed 'BAR' from disk (while also marking 'bar' deleted
in wc.db).

Some more explanation can be found in
http://svn.haxx.se/dev/archive-2011-09/0312.shtml.

A workaround is to execute the last 'svn rm' with --keep-local.

Note that this situation can't happen with 1.6 on Windows (except when using
--force), because (1) it can't have both 'bar' and 'BAR' in metadata at the same
time, and (2) if 'BAR' is an unversioned case-clash, 'svn rm bar' will always be
translated to 'svn rm BAR' (issue #3865), which will request --force to be used
in this situation.