Rendering Subversion version of HEAD

Anderson Lizardo lizardo at
Wed Jul 7 19:44:36 PDT 2004

On Sunday 04 July 2004 21:39, Kevin P. Fleming wrote:
> Anderson Lizardo wrote:
> > 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.
> 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.

Or then do in place editing of an existing .htaccess file (like using "sed 
-i"). But I think that recreating .htaccess file after each rendering is the 
most "reliable" solution.

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

Which reminds me: actually, a "stable" or "testing" renderings should only 
apply for tagged (I call them "inactive branches" :) trees (i.e. 
LFS/tags/<tag>/BOOK), otherwise readers will potentially have different 
versions of a stable or testing book if they are rendered from the "active" 

unstable will be either a live render from LFS/trunk/ or from a tagged tree, 
although I think it's up to the LFS editors decide how they want this 
specific branch to be rendered (that is, if they will make tags from unstable 
at all)

Hm, I'm still thinking that using those "render_*" properties would cause more 
trouble than using "stable", "testing" and "unstable" properties attached 
directly to svn:// (I suspect it's possble to 
attach properties on the highest repository level i.e. outside the trunk, 
tags and branches dirs). As you've said, it's easy to make two trees have 
"render_as: stable". Also, to switch the currently stable tree, the following 
operations are required:

svn propdel render_as # previous stable
svn propset render_as 'stable' # new stable

While the other aproach needs only:

svn propset stable 'tags/new_stable'

And finally, this aproach does not need scanning through the trees, as we know 
exactly where the properties are. As you see, both have their pros and cons 
(the fixed-property aproach needs the editor to type the repository path 
correctly, although the should exit with immediately if it 
receives a non-existant repository path; I have to implement this yet). 

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

For this separation between the "live" and "tagged" unstable rendering happen, 
the LFS editors should decide if they will actually tag unstable sometime. 
Personally, I don't think tagging unstable will be much helpful (except for 
marking "working" points before a really big change, for example), as testing 
branch (now reopened) is specially designed for this: prepare a more or less 
stable book ready for public testing.

So, if they eventually want non-dev people to actually test some feature from 
"unstable", they will branch it to "testing", I suppose.

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

Actually, I've just noticed that the number of renderings will not grow so 
quickly. Even if the editors change the version tag every day, there would be 
e.g. only 7 renderings per week of unstable. If only the latest unstable 
rendering is to be kept, we can use something like:

find -maxdepth 1 -name 'SVN-*' ! -name "$(readlink unstable)" \
	-exec rm -rf '{}' \;

Also see the commented out code on
Anderson Lizardo
lizardo at

More information about the lfs-dev mailing list