Daniel Sahlberg wrote on Thu, Mar 31, 2022 at 16:51:33 +0200: > Den tors 31 mars 2022 kl 16:29 skrev Nathan Hartman < > hartman.nat...@gmail.com>: > > > On Thu, Mar 31, 2022 at 10:12 AM Daniel Sahlberg > > <daniel.l.sahlb...@gmail.com> wrote: > > > > > > Den tors 31 mars 2022 kl 15:45 skrev Stefan Sperling <s...@elego.de>: > > >> > > >> On Thu, Mar 31, 2022 at 09:21:58AM -0400, Nathan Hartman wrote: > > >> > On Thu, Mar 31, 2022 at 9:09 AM Nathan Hartman < > > hartman.nat...@gmail.com> wrote: > > >> > > My bad. Hopefully r1899430 fixes it. > > >> > > > > >> > > How do I manually run backport.pl? > > >> > > > >> > Let me rephrase that question: How do I manually trigger it so we > > >> > don't have to wait for the cron job? > > > > > > > > > I'm guessing you figured out how to run the script! Did you use the Perl > > or the Python variation? I'm curious if the Python script is more powerful > > and better at handling merge failures. > > > > I just went ahead and ran it on my workstation, basically by checking > > out the branch, changing to its root directory, and running YES=1 > > MAY_COMMIT=1 ../svn-trunk/tools/dist/backport.pl. Which means I ran > > the Perl version. :-) > > > > It would be cool if there were a way to manually trigger svn-role do > > its thing, but it's not super important. > > > > Committing a "1" to STATUS.RUNNOW which is checked by a cronjob running > every minute? But then the problem below is still there. >
Suppose Infra gave PMC members a way to commit with svn:author=svn-role, would that solve the problem? > >> Related question: Why don't we run the cron job more frequently? :) FWIW, when backport.pl was written, I scheduled it to 04Z because that was a time when most developers were inactive, so it was unlikely to cause conflicts for people by merging a bunch of stuff halfway through their workday. That doesn't answer whether we should change the setting; just explaining where it originates. > > > I've also asked this question to myself. There was a discussion > > elsewhere (in the thread regarding migration of svn-qavm (in private@), > > quoted from memory) where someone mentioned a rare race condition with > > backport.pl if there was simultaneous commits to STATUS from someone > > else. This had happened some time in 2013 (?) when two cronjobs was > > executed simultaneous (on svn-qavm1 and svn-qavm2, during another > > migration) and they stepped on the toes of each other causing conflicts. > > There was a comment "this could happen also because of a manual commit to > > STATUS but we don't have so many commits at 04:00Z so the risk is quite > > low". I can't judge the risk of this. > > > > Hmm, I was going to suggest to run it more frequently around release > > time but the above sounds like a good reason not to!! Until it gets > > sorted out... > > > We should probably think about sorting this out. I'll dig out the original > thread and make a summary here, but not until after the relase. If you mean <https://mail-archives.apache.org/mod_mbox/subversion-dev/201610.mbox/%3CCABw-3Yf6-B2JOMj58ZQDCLLOSpgdXZOWXEDGi0-TEYsr2VFCsw%40mail.gmail.com%3E>, it was fixed in backport.py at the time. Cheers, Daniel
