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

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

-- 
Johan