On Wed, May 25, 2011 at 03:00, Bert Huijben <b...@qqmail.nl> wrote: >> 2011/5/24 Branko Čibej <br...@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
