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. Could you also do it also in the 1.10.x branch? For the benefit of the list, this is how it is executed by cron (expecting to have the active branches checked out in ~/src/svn/1.10.x, ~/src/svn/1.14.x etc. and also trunk checked out as ~/src/svn/trunk): for i in ~/src/svn/1.*.x; do cd $i && $SVN up -q --non-interactive && YES=1 MAY_COMMIT=1 ../trunk/tools/dist/backport.pl; done 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. Kind regards, Daniel
