Hi Richard --
> Does anyone in the list use any kind of version control (e.g. CVS) for
> the perl/template codebase of their website?
Every time! My team has been developing web sites with CVS for years now.
I can't imagine doing a web project without it! It would be like.. Oh...
Skydiving without a parachute?
> Now that my code base is growing I feel the increasing need to provide
> better version/backup control than my current hourly crontab tar.
> I don't however feel that the organizational logic of a websites code
> base fits well into the CVS paradigm. Am I being to short sighted in
> this assumption?
> Does anyone have any recommended method? I don't use version numbers at
> all? Does anyone?
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/
+ cron/
+ devdocs/
+ htdocs/
+ modules/
+ templates/
The "project/" directory is the CVS module, and is an identifier for the
project on which we are working. So, if we were hired to re-develop all of
Yahoo! in mod_perl (<*grin*>), the project directory might be "yahoo/". A
developer might check out a copy of the project with one command:
$ cvs co yahoo
All the other directories reflect the fact that every web site has "meta
content" beyond "htdocs" -- Perl modules, template files, etc. Here is a
run-down on the purpose of each directory:
apache/ - This directory contains a compiled Apache binary tree,
complete with configuration files, shared libraries, etc. This, combined
with CVS' branching and merging, has made upgrading Apache for our client's
sites a breeze.
bin/ - A directory for executable scripts and binaries related to
the project. These may be sys-admin utilities for managing bits of the
project or production web site. Every project ends up with a "tool box" of
these.
cron/ - Similar to "bin/", this contains scripts and executables.
Files in this directory are expected to be accessed via cron. I also put a
copy of the crontab file here so that it, too, can be version controlled.
Very useful.
devdocs/ - Documentation! You have some of that, right? :-) Also
included, any installation files (RPMs, packages, external source tarballs,
etc.) needed by the project.
htdocs/ - The hypertext documents directory. This is the directory is
mapped as the "document root" in your web server config.
modules/ - Project Perl modules. Via the web server configuration, the
PERL5LIB environment variable publishes the path to this directory so that
your code can find what it needs. Besides the code we write for a given
project, we also include *ALL* the CPAN Perl modules used for the project.
It has been a long time since I've had to "figure out" which Perl modules
are required for a web site.
templates/ - We use HTML::Template, and this path contains all the
external template files. (TT users can also use this structure.) Via the
web server configuration, the environment variable HTML_TEMPLATE_ROOT
publishes the path to this directory so that your code can find what it
needs.
Our environment is specifically designed to allow every developer, designer,
QA specialist, project manager, and client to have their own completely
independent, concurrent environment. CVS provides the glue for connecting
these environments. Other than the occasional FTP binary/ASCII mode upload
snafu, it is rare that developers on my projects step on each others' feet.
FYI, we work exclusively on UNIX. Our work is split roughly 80/20,
Linux/Solaris.
Warmest regards,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
