On Wed, Apr 20, 2011 at 11:22 PM, Johan Corveleyn <jcor...@gmail.com> wrote: > 2011/4/18 Branko Čibej <br...@e-reka.si>: >> On 18.04.2011 20:01, Johan Corveleyn wrote: >>> BUT it raises some additional questions/issues: >>> >>> - How to commit such a move? Committing the parent directory >>> recursively works fine, but if you try to specify only the move >>> targets (src and dst paths), commit runs into the same problem as what >>> I was trying to address here: both paths are converted to their >>> "truepath", which means only the added side is seen by commit (the >>> only part that's still on the filesystem): >>> >>> C:\Temp\test4>svn mv foo2 Foo2 >>> A Foo2 >>> D foo2 >>> >>> C:\Temp\test4>svn commit -mtest foo2 Foo2 >>> Adding Foo2 >>> >>> Committed revision 96322. >>> >>> This is very undesirable, because after this commit this cannot be >>> checked out or updated anymore on a Windows client (case-clashing >>> files). >>> >>> - In fact: the same problem holds true for other commands as well: how >>> to revert both sides of this move? Ok, one can revert in two steps ... >>> >>> - Maybe a more general solution is needed, so all commands can >>> adequately see which path the user actually means? The "truepath" >>> corresponding to a given path (modulo case), or really the path in the >>> case given by the user? A shot in the dark: (1) first look in the >>> wc-db - if the path matches a path in the wc-db, accept it as is, else >>> (2) convert it to its truepath (path on the filesystem that matches >>> modulo case). Except for "svn move", as implemented in this patch ... >>> >>> - Note that the above problem is already present now on trunk (without >>> my patch): since we can now represent case-clashing paths in the WC >>> even on a case-insensitive filesystem. (See Bert's example in [2], >>> "svn ren TODO todoQ; svn ren todoQ todo"). >> >> This is a larger question, and I believe it should be left for 1.8. In >> general, I doubt it's a good idea to allow users to commit or revert >> only one-half of a (local) move, at least not without --force; but >> that's the situation today. It would be even nicer if the client library >> were smart enough to automagically commit the deletion of the source of >> the move in "reasonable" cases ... and the solution would seem to be >> called "atomic renames". >> >> (Note that, if we had atomic renames as first-class citizens (in the WC, >> RA and FS), one could still simulate the current behaviour in those very >> rare cases when it's desirable simply by doing copy+delete explicitly.) > > Yes, I know about this problem, and I agree that it would be best to > leave a thorough solution for later ("atomic renames" certainly seems > the way to go, anything else would be more patchwork). So I realize > that the user currently has to make sure he commits both sides of the > move together (or let the UI do that for him). > > But the problem is that this is impossible in this case, with current > trunk code, at least with the cmdline UI in combination with > specifying explicit targets. After doing "svn mv TODO todoQ; svn mv > todoQ todo", one can never commit the scheduled delete of TODO, unless > committing the parent directory (or higher). Same with "svn rm TODO; > svn add todo" or similar. > > I think I should create a new issue for this problem, because it seems > more general than "making case-only renames work". It's a new problem > that can happen since WC-NG (wasn't possible before, I think, because > WC-1 would give errors at the point of adding the case-clashing file > to the working-copy). It's specific to the cmdline layer though, when > it tries to guess the targets the user really means, by looking for > the "truepaths" of the given targets...
For the record (and completeness of the archives), I filed this as issue #3865: http://subversion.tigris.org/issues/show_bug.cgi?id=3865 ('svn' on Windows cannot address scheduled-for-delete file, if another file differing only in case is present on disk) Cheers, -- Johan