Den mån 28 mars 2022 kl 09:55 skrev Daniel Sahlberg <
daniel.l.sahlb...@gmail.com>:
> This commit doesn't look correct.
>
> I executed the generate-upcoming-changes-log.sh manually yesterday and it
> created r1899244, removing a lot of log entries belonging to 1.14.1. This
> commit (which was executed by cron) restores them.
>
> The crontab entry is:
> [[[
> # Puppet Name: Update our upcoming changes list
> SVN=svn
> 15 4 * * * chronic ~/src/svn/site/tools/generate-upcoming-changes-log.sh
> ]]]
>
> The script begins with a comment
> [[[
> # This should be run from the root of a branches/1.{9,10,11}.x working
> copy.
> ]]]
>
> I suppose the crontab command should be changed to:
> cd ~/src/svn/1.14.x && chronic
> ~/src/svn/site/tools/generate-upcoming-changes-log.sh
>
So I've investigated this further and my initial analysis seems correct.
This is what happens:
* generate-upcoming-changes-log.sh determines last patch release number and
generates upcoming.part.html based on all commits since that patch release
was tagged.
* It has two different ways to determine "the last patch release":
* If `cwd` is a WC it look in the subversion/include/svn_version.h
* Else look in https://dist.apache.org/repos/dist/release/subversion/
* The logic looking at dists.a.o selected the oldest patch release
available on dists.a.o, in case there are more than one.
* The crontab entry executed generate-upcoming-changes-log.sh from ~, thus
forcing a lookup from dists.a.o
Currently, both 1.14.0 and 1.14.1 are available on dists.a.o. Thus it
emitted all merged changes since 1.14.0, while expected behaviour (of
upcoming.part.html) would be to only display merged changes since 1.14.1.
I've pushed a change in puppet to the crontab entry as suggested above.
This should solve the problem for now. When branching 1.15.x, we need to
update this crontab entry.
I don't have time right now to look at generating separate
upcoming.$VERSION.part.html files for the supported versions, but I will
leave it on the todo list.
/Daniel
