unstable branch for LFS
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