Re: SVN 1.7 problems with case insensitive file systems (Windows)

On Tue, Sep 13, 2011 at 1:32 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Mon, Sep 12, 2011 at 2:17 PM, Philip Martin
> <philip.martin_at_wandisco.com> wrote:
>> Philip Martin <philip.martin_at_wandisco.com> writes:
>>
>>> and the commit failed compaining the a/b/E is missing.  Now that commit
>>> works, on case-sensitive and case-insensitive filesystems, when the
>>> added tree is a mv with copyfrom.  Marc's mail appears to show that it
>>> fails on Windows when the added tree is a plain add without copyfrom.
>>
>> No, I'm misreading.  When Marc ran "svn rm" it appears to have marked
>> the missing tree as deleted, which is what we want, but also to have
>> removed the added tree from the disk.  The tree remains added in wc.db
>> but is missing from disk, and that leads to the failed commit.
>
> Yes, I think that's more or less what happens.
>
> I tried Marc's scenario with a simple file on Windows, printing status
> after every step:
>
> [[[
> C:\research\svn\experiment\wc\test4\foo>move bar BAR
>
> C:\research\svn\experiment\wc\test4\foo>svn st
> !       bar
> ?       BAR
> ### this is ok
>
> C:\research\svn\experiment\wc\test4\foo>svn add BAR
> A         BAR
>
> C:\research\svn\experiment\wc\test4\foo>svn st
> !       bar
> A       BAR
> ### this is ok
>
> C:\research\svn\experiment\wc\test4\foo>svn rm bar
> D         bar
>
> C:\research\svn\experiment\wc\test4\foo>svn st
> !       BAR
> D       bar
> ### this is wrong
> ]]]
>
> It seems your analysis is correct, in that the last step, "svn rm
> bar", removes BAR from disk, causing the problem.
>
> Also, if "svn rm bar" is performed first, BAR also gets deleted from
> disk, and you can't even add it anymore:
>
> [[[
> C:\research\svn\experiment\wc\test4\foo>move bar BAR
>
> C:\research\svn\experiment\wc\test4\foo>svn st
> !       bar
> ?       BAR
>
> C:\research\svn\experiment\wc\test4\foo>svn rm bar
> D         bar
>
> C:\research\svn\experiment\wc\test4\foo>svn st
> D       bar
>
> C:\research\svn\experiment\wc\test4\foo>svn add BAR
> svn: warning: W155010: 'C:\research\svn\experiment\wc\test4\foo\BAR' not found
> svn: E200009: Could not add all targets because some targets don't exist
>
> C:\research\svn\experiment\wc\test4\foo>dir /B
>
> ]]]
>
>
> However, it seems that adding --keep-local to the rm command is a
> workaround. It avoids the (wrong) local file to be deleted from disk:
>
> [[[
> C:\research\svn\experiment\wc\test4\foo>move bar BAR
>
> C:\research\svn\experiment\wc\test4\foo>svn st
> !       bar
> ?       BAR
>
> C:\research\svn\experiment\wc\test4\foo>svn add BAR
> A         BAR
>
> C:\research\svn\experiment\wc\test4\foo>svn st
> !       bar
> A       BAR
>
> C:\research\svn\experiment\wc\test4\foo>svn rm bar --keep-local
> D         bar
>
> C:\research\svn\experiment\wc\test4\foo>svn st
> D       bar
> A       BAR
> ]]]
>
>
> I don't have time to dig deeper and figure out a solution, but I think
> the problem is that the "rm" command will eventually execute
> svn_io_remove_file2, which will try to delete "bar" from disk (through
> various APR and/or Windows API's). But on Windows, when you try to
> delete bar while there is a BAR on disk, it will simply delete BAR.
>
> That said, in general "svn rm bar" *should* remove BAR from disk (if
> there isn't a "bar" in wc.db), because "svn" also performs
> case-canonicalization for its arguments, analogous to other tools on
> Windows.
>
> But it shouldn't do that in this special case, where the user wants to
> act upon another (case-clashing, missing-from-disk) item in wc.db.
> This situation is discovered in cmdline.c, lines 285 and following --
> the fix for issue #3865. I have no idea how to transfer that knowledge
> from cmdline.c to a keep-local flag for the delete command or
> something like that ...

I have filed this as issue #4023 (on Windows, 'svn rm' incorrectly
deletes on-disk file if it is case-clashing with intended
(non-on-disk) target) [1].

I think it's more severe than I thought at first, because it can
result in the loss of an uncommitted file. And this situation couldn't
happen on 1.6 (except when using --force).

I don't think it's a blocker for 1.7 (but maybe others disagree?),
because it's a rather edge-case scenario. But we should try to fix
this sooner rather than later. I don't have the time available right
now to dig into this (and no idea how to solve this), but maybe one of
the other (Windows) devs can take a look?

@Philip: was there also some other issue in this thread? You pointed
out several (other) problems in your initial reply.

[1] http://subversion.tigris.org/issues/show_bug.cgi?id=4023

-- 
Johan