Hallo Thom, Nachricht vom Friday, May 30, 2003, 1:05:12 PM:
> * Astrid Ke?ler ([EMAIL PROTECTED]) wrote : >> >> Hmmmmm, sorry. >> >> I'd see some alternatives >> >> - split the commit (e.g. by language) >> >> - create a new docs-cvs-mailinglist >> >> - drop the generated files and build the stuff online and for every release >> >> (RM job, resp. the tarball roller's) - would need some MBs of Java stuff >> >> installed everywhere >> >> - ? >> >> >> > I'd go with dropping the generated files out of CVS altogether - I don't see >> > that there's much reason to keep them there, and a teeny wodge of java is >> > not exactly an odious proposition for most of us these days I'd think? >> > Cheers >> > -Thom >> >> Don't drop them. It's usefull to know, whether they are up to date or >> not. But we do not need the commit mails. Only those mails need to be >> omitted. This should be possible. > I don't quite follow this I'm afraid - it's useful to know *where*? because > surely we can just have a check out and rebuild procedure on daedalus and > where ever else needs to have those files. The current workflow is to generate them locally and have the latest version in cvs (also the change management). Creating a release or updating the online docs, the generated html files are taken from the cvs. Of course, the RM could generate them while creating the release, or we could do the build process on deadalus, but what about generating content for languages with non ascii characters like japanese, chinese, etc.? As I understood, this depends partially on the local character set. May someone correct me, if I'm wrong. So if we need locally generation, we also need a place at the server to store the lastest version. Kess
