On Wed, Apr 20, 2011 at 11:22 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> 2011/4/18 Branko Čibej <brane_at_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
Received on 2011-04-24 21:31:47 CEST