julianf...@apache.org wrote on Fri, Sep 27, 2019 at 15:36:07 -0000: > +++ subversion/site/publish/docs/community-guide/releasing.part.html Fri Sep > 27 15:36:07 2019 > @@ -1494,22 +1494,28 @@ A.B with the version you're preparing, e > +<div class="notice">The following steps are not automated:</div> > +<ul> > +<li> > <p>Ask someone with appropriate access to add the A.B.x branch to the > <tt>svn-role</tt> backport mergebot:</p> > + <p>Someone with admin access to the <tt>svn-qavm</tt> machine needs to > + populate the a source directory for the new branch, by running,</p> > + <pre>sudo -u svnsvn svn up ~svnsvn/src/svn/A.B.x</pre>
Suggest to pass -H to sudo(8). It's not important in this case (nothing will write to the dotfiles), but it's a good habit. > + <p>The backport merge bot runs nightly on each such branch directory > + that exists.</p> > + <p>To remove a no-longer-supported branch:<p> > + <pre>sudo -u svnsvn svn up -r0 ~svnsvn/src/svn/Z.Z.x</pre> Why not just 'rm -rf'? As written, the cron job will just update back to HEAD on its next run… > + <p><i>[Obsolete note?]</i> > The exact checkout command is documented in machines/svn-qavm2/notes.txt > in the private repository (need to use a trunk client and the > svn-master.a.o > hostname).</p> The part about a 'trunk client' is obsolete. The VM used to have a /usr/local/svn-current/bin/svn client newer than the /usr/bin/svn. I don't remember why we started that (whether it was dogfooding out of general principles or some particular 'svn merge' bugfix we needed), but we don't do that any more. The part about using svn-master.a.o probably does matter, though. The backports merger runs «svn ci && svn up» in a loop, and assumes «svn up» will update it to the revision it just committed. That's not guaranteed when updating from the EU mirror (though few big merges get committed at 4am UTC, when the cron job runs). The buildbot slaves do this too, for the same reason. Cheers, Daniel
