[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvs development

>>>>> Gregory Leblanc <[email protected]> writes:

> Ahh, yeah, I see.  I guess that we probably need to define what kind
> of processing will be done on documents in the CVS repository.  I
> hadn't given any thought to pre-processing, since I don't have a
> "need" for it right now, nor time to figure it out.  The only things
> that had ocured to me was the processing of the SGML source into
> HTML/PS/PDF/Whatever.  If we're going to do pre-processing,
> especially if it will query an external database, then things will
> be HUGELY more complex.  Generating TOCs/Indexes from the SGML
> source shouldn't be that dificult, but querying external
> datasources, hm...  Thoughts?

I can easily rearrange my scripts to query by doing an http get
against my website.  The scripts themselves are part of the document,
and are just regular Perl, which we can provide on any reasonable CVS
server platform.  Add a few choice Perl modules and that's that.

But this doesn't really solve the real problem:

A particular version of my HOWTO is defined as the union of

 a) A particular version of my SGML source file, and
 b) The state of my database at the instant I commit/build

It's actually impossible for the full-blown automagic process to
reconstruct a historical version from CVS, because they removed
time-travel from Postgres.  At the moment, complete historical
versions exist out there in the ether, somewhere, maybe...

We can eliminate the confusion by me generating a full SGML file
locally and checking that in, but then (because checkins are not based
purely on checkouts) I become the only source of updates and it rather
defeats the `C' in CVS.  It also forces a schism in my existing CVS
file's history, since I've got several versioned components rather
than one complete SGML file.

Eons ago, Lars and I had half settled up on a system whereby most
HOWTOs would be built with a "stock" makefile, or a document could
come with it's own Makefile to do perverse things.  Between the GNU
make include mechanism and a bit of standard "install" and "build"
macro writing on your part, operations common to all documents and
particular to the build environment can be administratively
centralized.  If we do this, and arrange to build only on commit, then
both the problem of my build complexity and of my two-part versioning
snafu evaporate and we can all live happily ever after...

FWIW, I don't think you can really escape makefiles even without my
complicating presence: all those impending DocBook documents will
build mostly the same but will have assorted figures to massage.
Multi-component documents, like those with figures, are just way
easier to handle with the rule and dependency features of makefiles.

--
Grant Taylor - [email protected] - http://www.picante.com/~gtaylor/
    Linux Printing HOWTO:  http://www.picante.com/~gtaylor/pht/


--  
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]