On Wed, May 25, 2011 at 03:00, Bert Huijben <bert_at_qqmail.nl> wrote:
>> 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.
>
I'm fully agree with Bert that moving truepath conversion to
libsvn_client as bad idea and would introduct gigantic slowdown for
some Windows clients.
--
Ivan Zhakov
Received on 2011-05-25 06:35:50 CEST