We check in all of our perl modules into CVS and its a
_MAJOR_ life saver. Keeps everyone on the same path so to
speak.
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 <moseley@xxxxxxxx> wrote:
At 04:47 PM 10/30/02 -0500, Jesse Erlbaum wrote:
Web development projects can map very nicely into CVS.
We have a very
mature layout for all web projects. In a nutshell, it
boils down to this:
"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.
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@xxxxxxxx
