Den tis 27 maj 2025 kl 09:37 skrev Branko Čibej <br...@apache.org>: > On 26. 5. 25 23:15, Timofei Zhakov wrote: > > On Mon, May 26, 2025 at 10:07 PM Branko Čibej <br...@apache.org> wrote: > >> On 26. 5. 25 21:25, Timofei Zhakov wrote: >> >> On Mon, May 26, 2025 at 8:29 PM Branko Čibej <br...@apache.org> wrote: >> >>> On 26. 5. 25 14:07, Timofei Zhakov wrote: >>> >> >> This is exactly what happened with svn_cmdline__get_cstring_argv(). I >> added a new function svn_cmdline__get_utf8_argv(), that returns a utf8 >> string instead. Then we can switch the one used in each executable >> one-by-one. >> >> >> Those are private functions, you can do whatever you want with them, as >> long as you end up with only one version of each instead of, I dunno, five. >> >> > Those are also transitional functions needed to migrate all usages > smoothly. Probably it makes sense to drop the old ones then, but it would > not be a big deal for us in future... > > > > We have, what, 11 command-line tools? That's 11 one-line changes to make > the transition to the correct behaviour. It doesn't have to be done all at > once, but it shouldn't take years, either. Once all of those are fixed, we > should remove the unused private functions. If we make any new command-line > tools, we'll just have to get it right the first time. :) > > I believe there is a point in doing stuff incrementally - especially since this is a branch. There is nothing wrong with making checkpoint commits.
I agree with your overall concern about the naming of the functions - but why not: - Keep on as Timofei has started by adding a new _utf8_-named function (just to keep it clear what it is doing) - Migrate a few command line tools at a time to make sure we don't run into anything unexpected - When everything is done and the old _cstring_ version isn't used anymore, just remove it from the source - Removing _utf8_ - Committing each step along the way This way it is easy to check if/when something goes wrong. Especially since the GHAs keep testing each commit along the way. - When everything looks good we can check the diff against trunk and if it all looks good we can make a single big commit to trunk with the functions just magically behaving correctly and with appropriate names. Then we can delete the branch and pretend it never existed. A very experienced guy once asked for a bit of patience and that things might not get fixed right this second. I second that. Cheers, Daniel
