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. >> Related question: Why don't we run the cron job more frequently? :) > > > > 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. /Daniel
