I don't believe in transfering _any_ binaries around, every binary recompiles on its new platform at install time. All modules, apache, external software etc. This eliminates those pesky little problems that pop up when you start pushing binaries.
John-
On Wed, 30 Oct 2002 14:58:01 -0800
Bill Moseley <[EMAIL PROTECTED]> wrote:
At 04:47 PM 10/30/02 -0500, Jesse Erlbaum wrote:Web development projects can map very nicely into CVS. We have a veryThat requires binary compatibility, though. I have a similar setup, but
mature layout for all web projects. In a nutshell, it boils down to this:
"project/"
+ apache/
+ bin/
the perl and Apache are built separately on the target machine since my
machines are linux and the production machine is Solaris.
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'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.
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?
--
Bill Moseley
mailto:moseley@;hank.org
