julianfoad_at_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
Received on 2019-09-27 18:48:01 CEST