Rendering Subversion version of HEAD

Jeremy Utley jeremy at
Wed Jun 30 13:28:03 PDT 2004

Matthew Burgess said:
> On Wed, 30 Jun 2004 14:45:49 -0400
> Anderson Lizardo <lizardo at> wrote:
>> On Wednesday 30 June 2004 13:15, Matthew Burgess wrote:
>> > Randy McMurchy <randy at> wrote:
>> > > It appears that HEAD is being rendered and synced to the mirrors,
>> > > but it's what is in CVS and not Subversion. Is there going to be a
>> > > cutover date when Subversion will start being rendered during the
>> > > scheduled cron runs.
>> >
>> > I was going to respond to your previous post regarding this.  I'm
>> > going to attempt to get a render-on-commit going tonight.  That is,
>> > as soon as someone changes the book, a new version will be
>> > generated.  If this works out successfully then I'll declare
>> > (our current cron job script) obsolete for regular
>> > renders of the book, although it'll need to be made svn-aware for
>> > when a release is made.  Anderson, can you deal with this please?
>> Okay, I'm looking into it now.
>> BTW, Is it possible for the render-on-commit script just call
>> with the apropriate parameters? I'd like to avoid
>> duplicating the "core" code (i.e. the actual rendering code) if
>> possible.
> Err, yes of course.  Come to think of it, I don't know how I was
> thinking of rendering the book without using
> Probably just calling `make` directly I guess.  Anyway, I'll wait until
> you've looked into sorting the script out, then I'll tell subversion to
> do it's thing.
> Thanks,

Something to be aware of when trying to set up render-on-commit - whatever
commands are used to render will run as the user who *MAKES* the commit,
so all LFS editors will need to have write access to the directories where
the HTML is written to.

Another thing we MIGHT want to consider is adapting to run "make validate"
first, to ensure the commit is sane - if it isn't sane, write an error
back to the person doing the commit, and NOT render the book again.


More information about the lfs-dev mailing list