Hi Bill -- > > "project/" > > + apache/ > > + bin/ > > That requires binary compatibility, though. I have a similar setup, but > the perl and Apache are built separately on the target machine since my > machines are linux and the production machine is Solaris.
Binary incompatibility is not a problem for us because we generally develop on the same platform on which the final code will run. I've been bitten enough times that I don't like to wait until the proverbial last minute to test my code on the target platform. Part of our job is to make sure that *all* the parts of the system work -- even those developed by the Apache Software Foundation. ;-) After all, my client isn't going to accept the excuse that "our code is perfect -- it's that OTHER code!" At the end of the day, if we recommend Apache (or any other third-party code), we are expected to stand by it. That said, if you have to support multiple platforms for any reason (a Solaris to Linux migration, for instance... Hehe) you are right -- extra work is involved. Perl has a nice structure for dealing with multiple architectures (arch library paths "i686/", "sun4/", etc.) but you will have to devise something else for application like Apache. > I only work on single servers, so things are a bit easier. I > always cvs co > to a new directory on the production machine and start up a second set of > servers on high ports. That lets me (and the client) test on the final > platform before going live. Then it's "apache stop && mv live old && mv > new live && apache start" kind of thing, which is a fast way to update. I don't like any system which requires you to make any "last minute" changes. If you test on port 8080, there is no proof that you won't have problems when you move to port 80. What happens if a developer has clumsily hard-coded ":8080" into a link to solve a problem in testing? I've seen it happen a thousand times, even to very smart programmers. If you have root access on the server you would be better off binding an additional IP address and running the stage server there, IMHO. > I'd love to have the Perl modules in cvs, though. Especially mod_perl > modules. It makes me nervous upgrading mod_perl on the live > machine's perl > library. Should make more use of PREFIX, I suppose. That is more or less how you do it. I have a module build process which allows me to build ALL modules in user space, isolated from the host operating system. If you put CPAN modules (including mod_perl) in CVS you will even be able to select versions. I've had forward-compatibility problems with CPAN modules in the past. Being able to run an old version of a library for one site, and a different version on the host machine is a really helpful thing. Note that if you want to put mod_perl in CVS you *have* to also put an Apache binary in mod_perl. There is no way around it. I've created an Apache mod_perl build process which automates compiling in user space: http://www.erlbaum.net/Apache-Perl-SSL/ HTH! > Speaking of cvs, here's a thread branch: > > I have some client admin features that they update via web forms -- some > small amount of content, templates, and text-based config settings. I > currently log a history of changes, but it doesn't have all the > features of > cvs. > > Is anyone using cvs to manage updates made with web-based forms? Humm... You're talking about revision control on databases. That's a really difficult thing. In short, it's not possible to revision control a SQL database. If you have data which needs to be revision controlled put it in XML or in a Perl module. Another thing to add: Only files which are directly managed by a developer can be effectively managed in CVS. Files which are changed through a web form or an automated process are not candidates for CVS because the automation can't usually do important things like commit changes and resolve merge conflicts. I actually create a directory hierarchy outside of CVS, generally called "EXTERNALS/", to store files which are managed through automation. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
