Hi, > Seems to be mostly German... No compile farm that I could find, but has > ssh and apache (oh, and MySQL ;-). Details at > http://developer.berlios.de/docs/site/services.php > > FWIW, the SF compile farm isn't really my bag either. But it does > support Solaris 8 SPARC-64, x86, PPC, SPARC, and Alpha Linux (all > elderly Debian 2.2?), x86 FreeBSD, and now Mac OSX.
Well, I learned to appreciate it, but I do understand arguments for berlios.de. How about http://savannah.nongnu.org/ > Development should of course continue to be x-platform. But Lintel only > support+testing from OSDL is still beneficial. Sure is. Load is a load, I say... :-) > > > From Daniel's post, it sounded like we whould run a full custom cvs > > > tree, changes would/could be integrated at the vmake stage? > > > > I was under the impression we can just checkout official CVS, and add files we > > want to replace in separate directory? > > That works too. I was thinking of keeping a complete cvs tree, and > diffing the official one to the external one to find modified files. I > just liked the idea of having something "complete", rather than just a > filestore of patches... Did you try compiling SAP DB from source code? Try running diff on all of it, just for fun... :-) We can keep a mirror of SAP DB CVS, probably as read only if you ask me, but I'm a little worried about maintaince of that mountain of code if it's not read only. So I personally vote to use SAP DB CVS (...and hoping, and dreaming...) and keep in OpenSAPDB CVS only changed files, and make patches from that, and release them. Yours, Andrej Falout, http://www.falout.com/disclaimer.html Project manager, Aubit project: http://aubit4gl.sourceforge.net Software architect, MakeTXT.com PLEASE NOTE: All HTML email sent to me WILL BE DELETED AUTOMATICALLY WITHOUT READING. _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
