Rendering Subversion version of HEAD

Anderson Lizardo lizardo at
Sun Jul 4 17:39:31 PDT 2004

On Sunday 04 July 2004 18:26, Kevin P. Fleming wrote:
> Anderson Lizardo wrote:
> > IMHO that "scanning" would actually only be useful if we decide to
> > continue using cron for running nightly builds. But with a post-commit
> > process that would not be needed anymore, as is more resource-savy to
> > only render the trees that have changed _and_ are marked with the
> > "render_to" (or "render_me" :) property.
> Yes, that is the ideal situation. Put a "render_to" property on the BOOK
> directory of any tree you want rendered, with the value of the property
> being the name of the directory/filename that it should be rendered into
> (under /lfs/view and /lfs/download). An additional property called
> "render_stable" could result in _that_ render being linked to as stable
> (using the .htaccess linking method I proposed before). Same goes for a
> property called "render_testing", that would be linked as testing.

The new script I've just put on-line extracts the version 
string directly from general.ent. Although this seems weak (in case this file 
is moved, for example), I think this method bring less work for the editors.

So, as the directory to be created on lfs/{view,downloads} is inferred, what 
about having a unique "render_as" property, whose value should contain the 
"alias" for that tree? E.g.

render_as: stable

Having a fixed property name also makes unstable->testing changes easier, 
requiring only "svn propedit" instead of "svn propdel" and then "svn 
propset". The query for the value is also a simple

svn propget render_as svn://$svn_path

(where $svn_path is trunk or tags/v5_1_1, for example)

Regarding your previous RFC: do you think the look for the render_* properties 
and the creation of the .htaccess files should be done still on the 
post-commit script (it would work like the "wrapper script" you proposed on 
the original text), or should be done directly on

> Do you want to work together on this to get it working on a cron-job
> basis, and then it can be moved to on-commit later?

Ideally, I'd like to see the cron job disabled as soon as the render-on-commit 
scheme is enabled. If you think the .htaccess file should be handled by, then your previous suggestions can be applied even before 
render-on-commit goes on-line.

PS.: Your previous RFC did not mention how we should handle the unstable 
(trunk) branch. My suggestion is to make "unstable" a real directory, instead 
of a symlink (as it is now) or .htaccess rule. The reason for this is that, 
as the trunk changes very often (including its "version" entity) the 
lfs/{view,downloads} dirs will soon have a lot of SVN-* dirs. Having a real 
unstable directory, It will be removed before each rendering of the trunk.

Anderson Lizardo
lizardo at

More information about the lfs-dev mailing list