On Sun, May 29, 2011 at 9:42 AM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
> On 29.05.2011 08:43, Johan Corveleyn wrote:
>>
>> On Tue, May 24, 2011 at 11:02 AM, Johan Corveleyn<jcorvel_at_gmail.com>
>> wrote:
>>>
>>> 1) Rev svn_client_args_to_target_array to take an argument "is_move".
>>> That's really the only case where something special needs to happen.
>>> Something like this:
>>>
>>> if (is_move&& input_targets->nelts == 2
>>> && strcmp(original_dest_target, true_dest_target) != 0
>>> && strcmp(true_src_target, true_dest_target) == 0)
>>> /* Case-only rename on Windows.
>>> Use original_dest_target instead of true_dest_target */
>>>
>>> 2) Rev svn_client_args_to_target_array to simple always return the
>>> original target list, as well as the truepath converted ones. Then let
>>> move_cmd.c figure it out (i.e. implement the above logic).
>>>
>>> 3) Leave svn_client_args_to_target_array alone, and just re-implement
>>> (copy-paste) the logic to create the 'master array of targets' inside
>>> move_cmd.c (combining the targets from apr_getopt plus any extra
>>> targets (--targets)), so it can do all that it needs itself...
>>
>> Sooo, I still haven't seen a clear preference for one of the
>> approaches I suggested. To rephrase:
>>
>> 1) Push more information into svn_client_args_to_target_array, so it
>> knows when to undo truepath conversion (i.e. a flag 'is_move', or if
>> that's too specific let's call it
>> 'avoid_dual_target_truepath_collision' or
>> 'keep_dest_origpath_on_singlesource_truepath_collision' or something,
>> because that's essentially what it does)
>>
>> 2) Let svn_client_args_to_target_array return more information, i.e.
>> the original paths (it has this information already), so move_cmd.c
>> can use this to undo the truepath conversion if needed. All other
>> callers of svn_client_args_to_target_array would just drop this
>> information on the floor, because they don't need it (alternatively,
>> it probably makes sense to make the output parameter optional (NULL if
>> it's not needed)).
>>
>> 3) Re-implement part of svn_client_args_to_target_array inside
>> move_cmd.c, so it can re-fetch the original paths when it needs them.
>>
>> I personally prefer 2 (with an optional output parameter). Other
>> opinions? More ideas?
>
> Since TSVN doesn't use that function but uses its own command line parsing,
> I can't really tell you what's best.
>
> For clients (consumers of the svn API) I think 1) would be best. Because
> then all clients that use this API will behave the same and don't have to
> implement their own version to deal with it.
>
> But 2) would be fine too - if someone doesn't know how to use this and deal
> with it, they can always look at the code in move_cmd.c and see how it
> should be done.
Thanks for your feedback, Stefan.
Ok, I think I'll go for 1, as you suggest. Now I only need to find a
good name for the flag ... I think I'll settle for
'keep_dest_origpath_on_truepath_clash' for now. If someone has a
better idea, feel free to bring it up :-).
Only move_cmd.c will pass TRUE for this flag. All other subcommands
will not expect/want this behavior (e.g. 'svn commit A a', when there
is only A on disk, is expected to just succeed on Windows (at least it
does so now), and not fail with 'a is not under version control').
> btw: the case-only renames work perfectly in TSVN now, just running my final
> tests with this :)
That's good to hear :-). At least it confirms that most other clients,
apart from the command line client, should already be able to handle
this.
--
Johan
Received on 2011-06-01 00:39:27 CEST