> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
> Sent: woensdag 25 mei 2011 0:45
> To: Branko Čibej
> Cc: dev_at_subversion.apache.org
> Subject: Re: [RFC] Final approach for issue #3702 (case-only renames on
> Windows)?
>
> 2011/5/24 Branko Čibej <brane_at_e-reka.si>:
> > On 24.05.2011 11:02, Johan Corveleyn wrote:
> >> Hi,
> >>
> >> After issue #3865 [1] got fixed, and the client-layer parts of #3702
> >> [2], there is one remaining hurdle to #3702: during argument parsing,
> >> the command line client 'svn' should detect the attempted 'case-only
> >> rename', and in that case pass the original destination path to the
> >> client layer, instead of the truepath converted one. I'm unsure of the
> >> best approach here, so I'm asking for some feedback.
> >
> > I think the correct way to handle this is to move the truename
> > conversion from the client to libsvn_client. This is quite a bit of
> > work, but othewise every client in the world will have to do /something/
> > to implement true renames, and I don't think that's a reasonable
> > requirement.
> >
> > I'm trying to find reasons why doing this would create and API
> > incompatibility, but for now I can't think of one.
>
> I'm not sure I fully understand. I must admit that I don't know how
> other clients use these codepaths, I have only looked at the svn
> command line client.
>
> AFAICS, truepath conversion is already done in the libsvn_client
> (namely in cmdline.c#svn_client_args_to_target_array). Is this only
> used by the svn command line client (the filename cmdline.c seems to
> suggest that)? Or do other (GUI?) clients use this as well? In any
> case it's part of libsvn_client.
>
> However, the problem is that this is a generic function that's being
> called from just about every *-cmd.c file in subversion/svn. It's
> usually the first thing they do, before starting to use the arguments
> for whatever.
>
> Being a generic utility function, it just
> canonicalizes/truepath-converts whatever it receives. But it doesn't
> have enough knowledge to discover this special-case scenario for the
> move. That's why I thought about adding an extra boolean argument
> "is_move". That's the only exception where truepath conversion might
> need to be undone.
>
> So I just can't see this working without passing extra info from the
> command to the client layer. Otherwise it just doesn't have enough
> info about what you're trying to do.
>
> If you are suggesting to remove the current truepath conversion from
> svn_client_args_to_target_array (letting it only canonicalize path
> separators), and moving it into each single command of the client
> layer (and each utility function that now expects an
> already-truepath-converted-path) ... hmmm ... that would be a big
> change, and a huge amount of work IMHO. But maybe I'm misunderstanding
> ...
And moving this into all apis of libsvn_client would introduce a gigantic slowdown for Windows clients, that use different approaches to only do the truepath conversion only when absolutely possible.
For VisualSVN and AnkhSVN this performance penalty would require patching this out just to keep the performance acceptable. (Ivan and I touched this subject in Berlin last week). I think the same thing applies for TortoiseSVN.
So -1 on adding this slowdown to all libsvn_client functions just because you want to make it easy; as this just makes it much harder for at least these clients and probably many others.
It would also break backwards compatibility by introducing unexpected path translations everywhere... Thereby introducing the specific problem Johan tries to fix for all existing clients in many other cases.
Note that this truepath support is windows only. APR ignores truepath requests via its api on all other case insensitive platforms.
Bert
>
> --
> Johan
Received on 2011-05-25 01:01:25 CEST