On Sun, Mar 20, 2011 at 3:32 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> I'm looking at issue #3702 ("svn ren TODO todo" not work on windows).
> Although this is marked as "1.7-consider", I'd really like this to be
> fixed before release, since this is pretty important for me and my
> user base. So I'd like to take a stab, but being relatively
> inexperienced, I'd like some help ... OTOH, if someone more
> experienced can fix this easily, that would be fine too :-).
All 1.7-consider means is "sure, we'd like to have it in there, but we
aren't going to hold the release for it". It *does not* mean "there
is no way this is getting into the release." These characterizations
are of course subjective and fluid, and if it gets fixed before 1.7
branches, ain't nobody gonna stand in the way of releasing it.
I've only skimmed the rest of the mail, and have no comments, but
wanted to make sure the 1.7-consider-ness of the issue didn't dampen
> As explained by Bert in
> the remaining issue here is that the command line client normalizes
> all paths to their on-disk casing, before passing the paths to the
> client layer. Or, following the code:
> -> svn/util.c#svn_cl__args_to_target_array_print_reserved
> -> libsvn_client/cmdline.c#svn_client_args_to_target_array
> -> libsvn_subr/opt.c#svn_opt__arg_canonicalize_path
> -> apr_filepath_merge(... APR_FILEPATH_TRUENAME ...)
> ^^^ normalizes case, as indicated by flag ^^^
> -> pick dst_path of the list of targets
> -> call libsvn_client/copy.c#svn_client_move6
> So: all the target paths of the command are normalized first, and only
> after that the dst_path is taken as the last target. By then it's
> already transformed to on-disk-casing. I don't really know how to go
> about this.
> Some thoughts:
> - There is only a problem if the dst_path gets case-normalized to one
> of the source paths. Otherwise, the case-normalization really does
> need to happen.
> - Maybe: let it be case-normalized like it is now, together with
> everything else, but check afterwards if it's now identical to one of
> the source paths. If so, transform back to the original case? Or throw
> it again through a canonicalization routine, but without changing
> - Since svn_cl__args_to_target_array_print_reserved and lower are
> blissfully unaware about what the targets are for (source or dest),
> the only place to start the "alternative path" for handling dst_path
> would be move_cmd.c#svn_cl__move itself.
> - Other useful things happen inside svn_client_args_to_target_array
> and svn_opt__arg_canonicalize_path (and in apr_filepath_merge modulo
> the APR_FILEPATH_TRUENAME flag), besides the case-normalization. Those
> other things probably also need to be done to dst_path, even if it's
> not case-normalized. Is there already some code for that?
> Any input is appreciated.
> How do other svn clients handle this (or will handle this)?
Received on 2011-03-22 01:09:15 CET