If memory serves me right, "B. W. Fitzpatrick" wrote:
> The problem is this: If we put a keyword in book.xml in order to
> display a revision number on the cover of the book, it's only going to
> display the last revision in which book.xml changed--and it rarely
> changes. ch0*.xml and app*.xml change all the time, but that wouldn't
> be reflected on the cover.
Duh. I should have realized that. I do a bunch of work on FreeBSD's
documentation, which has a similar problem, except we don't have
> Now there are a couple of possible solutions for this (I was just
> chatting with Sander on irc about this actually):
> - Tweak the Makefile to scrub through your working copy (ala
> svnversion) and generate a revision number which it would inject
> into book.xml before making the pdf, html, or whatever.
> - Add a new feature to Subversion (post 1.0, of course) to provide a
> keyword that reflects the HEAD revision of the repository that the
> working copy belongs to.
> If you want to take on the former and submit a patch, I would be more
> than willing to review and incorporate it.
I'll think about this, but if someone else gets to it first, that's fine
by me. I'd maybe use the output from svnversion (suitably munged) to
construct a short file that defined a XML entity for the version number.
Then book.xml can just include the new file (which would get built as a
dependency) and refer to the entity in-line without us needing to touch
the WC XML source files. I'd also do a check to handle the case where we
weren't really building inside a WC (e.g. someone downloaded a tarball
and wanted to build the book).
Received on Tue May 6 20:56:28 2003
- application/pgp-signature attachment: stored