re-rolling PDFs and HTML archives of version "1.6" of book withot changing file names
stsp at elego.de
Mon Oct 31 16:02:36 CDT 2011
On Mon, Oct 31, 2011 at 03:40:41PM -0400, C. Michael Pilato wrote:
> But I fail to see why this problem is unique to svnbook. The Subversion
> project itself does not produce binary artifacts -- just a source tarball.
The difference here is that every Subversion source tarball we release
has a distinct name because the version number is included in the name
of the tarball.
> So presumably there is a FreeBSD build server or build artifact library that
> contains binary builds of Subversion which are versioned to accommodate
> users with differing pedigrees of FreeBSD installed. Could such a system
> not also house versioned drops of the Subversion book HTML/PDF artifacts,
> and your Subversion port be configured to consult *that* system (instead of
> the svnbook.org website) for those bits?
While FreeBSD mirrors could host their own fixed versions of the book,
it would be a great service for them and others if we made stable
versions available for download. This problem does not only affect
FreeBSD, but any OS providing the book via installable packages.
Does red-bean have enough space to keep the latest N builds of the
book available? FreeBSD has a distfiles mirror to protect against
distfiles disappearing from the upstream site. If we kept, say, the
last 50 builds of the book ready for download, with the revision number
in the name of the tarball, it would fix the problem for FreeBSD and
other packagers, preventing them from having to roll their own fixed
distribution tarball of the book for their users to install from.
By the time the 50th build of the book disappears from red-bean, it will
already be mirrored on the entire FreeBSD distfiles mirror infrastructure.
More information about the svnbook-dev