Re: [RFC] Final approach for issue #3702 (case-only renames on Windows)?

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.

btw: the case-only renames work perfectly in TSVN now, just running my
final tests with this :)

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net