Rendering Subversion version of HEAD

Kevin P. Fleming kpfleming at linuxfromscratch.org
Wed Jul 7 20:20:29 PDT 2004


Anderson Lizardo wrote:

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

Agreed.

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

That makes sense, but I don't know how the book editors will feel about 
that. Personally I think it would be the perfect thing to do for 
"testing" so that when people report testing results they have an actual 
date they can report against and others can review that specific set of 
instructions (in case it has been changed in in the intervening time). 
However, I frequently plan for events that will likely never occur 
(that's my job, after all <G>), so this may be overkill. It's cheap to 
implement, though.

> While the other aproach needs only:
> 
> svn propset stable 'tags/new_stable'

I like this too; properties can be attached to any versioned object in 
SVN, directory or file. I don't see any reason why they couldn't be 
attached to /LFS, or /LFS/trunk/BOOK, or even /LFS/BOOK (if the LFS repo 
gets rearranged the way I'm going to rearrange the ALFS repo).

> 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 render-lfs-book.sh should exit with immediately if it 
> receives a non-existant repository path; I have to implement this yet). 

I believe this is the safest approach and easiest for the editors to 
deal with as well. These tags will not be changing frequently, so 
they're not going to have to do this often.

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

That's still open to debate; current thinking appears to be that 
"testing" gets created only when there is a well-defined set of things 
to pull from unstable and stabilize so they can get moved to "stable" as 
soon as possible. My thinking with not having /alfs/view/unstable be a 
live render was for those people who are doing manual builds and can't 
complete them in a short period of time (say, one or two days), this 
makes it possible for them to either return to an unchanged book 
(because no new tag has been created since their last visit), or to have 
stored a bookmark (the reason for the .htaccess file, so they can return 
to that same version).

Again, this could be overkill, but it's cheap to implement, and those 
editors who wanted a live render before were satisfied having the only 
_live_ render be linked to off of the "Development (SVN)" page, rather 
than via the "unstable" link on the main page.

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

See above; I believe this sort of thing will happen more often than 
that, like for gcc/glibc upgrades, major package additions, etc. It 
makes sense to produce date-based tags before those changes so that 
people doing builds can complete their build without getting a mixed set 
of instructions from multiple visits.



More information about the lfs-dev mailing list