On Sun, May 29, 2011 at 9:42 AM, Stefan Küng <tortoise...@gmail.com> wrote: > On 29.05.2011 08:43, Johan Corveleyn wrote: >> >> On Tue, May 24, 2011 at 11:02 AM, Johan Corveleyn<jcor...@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