How The Download Page Works
Except, the "Source Tarball" download products are not stored as unversioned files. They are computed on-demand by the /tarball web page.
When a new version is generated, the developers use the fossil uv edit command to make minor changes to the "download.js" file so that it knows about the new version number. Then the developers run the fossil uv add command for each build product. Finally, the fossil uv sync command is run to push all the content up to servers. All three self-hosting repositories for Fossil are updated automatically.
The current text of the "download.html" and "download.js" files can be seen at:
The default mimetype for "download.html" is text/html. But because the entire page is enclosed within
<div class='fossil-doc' data-title='Download Page'>...</div>
Fossil knows to add its standard header and footer information to the document, making it look just like any other page. See "embedded documentation" for further details on how <div class='fossil-doc'> this works.
Build products need to be constructed on different machines. The precompiled binary for Linux is compiled on Linux, the precompiled binary for Windows is compiled on Windows10, and so forth. After a new release is tagged, the release manager goes around to each of the target platforms, checks out the release and compiles it, then runs fossil uv add for the build product followed by fossil uv sync to push the new build product to the various servers. This process is repeated for each build product.
When older builds are retired from the download page, the download.js page is again edited to remove the corresponding entry from the "release" variable and the edit is synced using fossil uv sync. This causes the build products to disappear from the download page immediately. But those build products are still taking up space in the unversioned content table of the server repository. To purge the obsolete build products, one or more fossil uv rm commands are run, followed by another fossil uv sync. It is important to purge obsolete build products since they take up a lot of space. At /repo-tabsize you can see that the unversioned table takes up a substantial fraction of the repository.
Only users with the "y" permission are allowed to push unversioned content up to the servers. Having the ability to push check-ins (the "i" permission) is not sufficient.
On the Fossil project there are 67 people (as of 2017-03-24) who have check-in privileges. But only 3 core developers can push unversioned content and thus change the build products on the download page. Minimizing the number of people who can change the build products helps to ensure that rogue binaries do not slip onto the download page unnoticed.