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...
Cheers,
--
Johan
Received on 2011-04-20 23:23:41 CEST