* 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. I don't get why having this stuff in cvs actually helps us at all - we're not making any changes to it directly, so it doesn't need to be under change management. Same as the configure scripts, and all the other generated code. Cheers -Thom
