Rendering Subversion version of HEAD

Kevin P. Fleming kpfleming at linuxfromscratch.org
Sun Jul 4 18:39:23 PDT 2004


Anderson Lizardo wrote:

> The new render-lfs-book.sh 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.

OK, this makes sense to me.

> 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

This would be perfect. If someone accidentally marks two trees with 
render_as "stable", they get what they deserve :-)

> Having a fixed property name also makes unstable->testing changes easier, 
> requiring only "svn propedit" instead of "svn propdel" and then "svn 
> propset".

Right, very simple.

> 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 render-lfs-book.sh?

I think it makes sense to leave render-lfs-book.sh as a script that 
takes the appropriate parameters and renders a book where the user asks 
it to. That way it's still usable by editors who want to produce a 
private render, or someone who wants to render an untagged tree.

IMHO that means any script that looks at SVN properties to find out what 
to render (either on a scheduled basis or post-commit) would just invoke 
render-lfs-book.sh, possibly multiple times, as it finds work to do.

> 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 
> render-lfs-book.sh, then your previous suggestions can be applied even before 
> render-on-commit goes on-line.

Hmm, now I see what you mean with previous question... Logically, 
rendering and .htaccess creation should be distinct operations, since 
they are not really directly related. The problem with the .htaccess 
solution, as much as I like it, is it has to be entirely rewritten every 
time, and that means a script has to look at all the SVN trees to find 
out what should go into .htaccess.

I believe that means there should be a separate script that does only 
that task, and it can be called as the last step of the current cron 
job, or as the last step of a post-commit trigger.

> 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.

I am of mixed feelings there; I would rather see the viewable book on 
the website _not_ be a "live" render of the SVN repo, because then it 
can change underneath readers. However, given the fact that it's called 
"unstable", we can make people realize that even the book contents 
themselves are not stable.

IIRC, the discussion that we had before resulted in the "unstable" 
directory being a live render, but only viewable via the "Development 
(SVN)" page, not via the "view/unstable" link on the LFS page. That link 
(view/unstable) would point to some tagged version of the unstable trunk 
when the editors felt it was ready to be rendered for any casual reader 
to read. This works nicely with the SVN properties, because when the 
editor makes that tag, they can add the "render_as: unstable" property 
on it as well, and it becomes the next "public" unstable book render. 
The unstable directory itself would always be a render of 
LFS/trunk/BOOK, with no use of SVN properties involved.

This would keep the number of "old" unstable renders in /lfs/view down 
to only the number of tags that the editors make throughout a 
development cycle, and of course there could be a cron job to remove 
anything older than 30 days.



More information about the lfs-dev mailing list