On Tue, Sep 13, 2011 at 1:32 AM, Johan Corveleyn <jcor...@gmail.com> wrote: > On Mon, Sep 12, 2011 at 2:17 PM, Philip Martin > <philip.mar...@wandisco.com> wrote: >> Philip Martin <philip.mar...@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
