unstable branch for LFS

Matthias Benkmann matthias at winterdrache.de
Tue Oct 15 13:38:28 PDT 2002

On Tue, 15 Oct 2002 14:10:33 -0600 Gerard Beekmans
<gerard at linuxfromscratch.org> wrote:

> On October 15, 2002 06:15 am, Matthias Benkmann wrote:
> I'm about 300 lfs-dev emails behind, so i'll try to catch up asap. 

Don't despair. 100 of those just contain the word "Grub" or "Lilo" :-)

> So I propose this: we can use one and the same XML tree to house both
> the unstable and stable books. Anybody remember me talking about
> dynamically render a customized lfs-book by switching some XML tags that
> add/remove certain pages/chunks from the book?
> Similarly we can easily add "unstable" XML sections that are only
> visible when you enable an entity. If disabled (by default) a normal
> stable book is renderred.

I think a CVS solution would be better. Keep 2 branches checked out:
unstable and mainline. If you make a change in a common file (most of the
explanatory text will be common) you make it in the unstable tree, issue
commit and then merge for the file. You should probably write a script
"comm" that would check if the file is a common file and in that case
issue commit and merge and otherwise just a commit.
If you make a change to a file that is not common, just make it in the
respective branch and commit as usual.
For distinguishing between common and non-common files I suggest to use
tags. The build instructions for instance would be common for most
packages, but if a change is made so that the branches need different
build instructions, then you would just tag the respective file as
non-common and your "comm" script can check that using "cvs status -v |
grep -q non-common" and will not do a merge if that file is changed.
If at some future point, the build instructions for both branches are the
same again, just remove the non-common tag and the "comm" script will do
the merge again.

Disclaimer: I'm not a CVS expert and I know almost nothing about the LFS
source tree. This is just an idea.


Ambition is a poor excuse for not having enough sense to be lazy.

Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list