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. >> 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... Cheers, Nathan
