sön 8 juni 2025 kl. 15:27 skrev Timofei Zhakov <t...@chemodax.net>: > On Sun, Jun 8, 2025 at 1:03 PM Daniel Sahlberg < > daniel.l.sahlb...@gmail.com> wrote: > >> >> >> sön 8 juni 2025 kl. 12:47 skrev Timofei Zhakov <t...@chemodax.net>: >> >>> On Sun, Jun 8, 2025 at 2:48 AM Branko Čibej <br...@apache.org> wrote: >>> >>>> On 7. 6. 25 19:41, rin...@apache.org wrote: >>>> >>>> Author: rinrab >>>> Date: Sat Jun 7 17:41:22 2025 >>>> New Revision: 1926218 >>>> >>>> URL: http://svn.apache.org/viewvc?rev=1926218&view=rev >>>> Log: >>>> In the trunk: Add svn_cmdline__get_utf8_argv() function and >>>> platform-specific implementations. >>>> >>>> >>>> You don't need to say "in the trunk" for trunk commits. >>>> >>>> >>> I know, but why not? >>> >> >> For brevity? >> >> >>> >>>> >>>> (merged from utf8-cmdline-prototype@r1925816) >>>> >>>> >>>> Please don't do that. You have an (experimental) feature branch, which >>>> we're at some point going to review in depth; and now it will no longer be >>>> trivial to see (e.g., with only "svn log --diff" what's changed on the >>>> branch and what's merged to trunk. Stuff like this makes reviewing new >>>> features much, much harder. >>>> >>>> >>> I prefer to plan my work in a branch, so I can freely break some >>> functionality, and then commit those changes to trunk one-by-one, and >>> pretend we never had this branch before. This way, I am getting the work >>> done, and committed properly. The changes can be reviewed as they are >>> committed to the trunk. >>> >> >> I’m with Brane on this point. >> >> I was planning to review this in the branch and then we could wholesale >> merge it. Cherrypick merging seems prone to missing something. >> >> > Fine, I can prepare this branch for reviewing (revert or cherry-pick > unrelated changes), so the diff would be clean, without those experiments. > > But still I am going to cherry-pick the remaining changes one-by-one into > the trunk, because I prefer having a bunch of small changes instead of a > code-bomb after svn-merge. > > Are we okay with that? >
I’d want to make sure that all revisions are - in the end - merged, so that trunk == branch at the time of merging. Just to make sure we don’t end up with something different in trunk vs the branch. How to reach that goal is probably not very important as long as the mergeinfo is uptodate. Cheers Daniel
