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.)
-- Brane
Received on 2011-04-18 21:48:29 CEST