On Wed, 8 Mar 2000, Herouth Maoz wrote:
> The normal method of working with CVS is to have a private working
> directory, where we change, test, and when satisifed, commit to the
> (internal) server where others can QA it.
>
> This is a problem: The site is a dynamic one, meaning it's definitely
> not simple HTML. Testing even a simple color change needs an actual web
> server, database connection, PHP installation, and whatnot. Having such
> a setup on each of the developer's computers is redundant - a
> maintenance nightmare.
Here's what I've done: First, I came to the conclusion that the designers
(as separate from "engineers") don't need to have direct, immediate access
to a dynamic server as long as they can preview the HTML locally. Second,
I decided that engineers did need direct access.
So, the engineers each get their own separate server on the dev machine.
They're traditional working areas, with no auto-update and whatnot. The
port number for them is determined automatically by running:
port=`echo "$LOGNAME $root" |sum |awk '{print $1}'`
port=`echo "$port / 6 + 1024" |bc`
on Linux, or
port=`echo "$LOGNAME $root" |sum |awk '{print $1}'`
port=`echo "$port + 1024" |bc`
on Solaris.
There's also a single shared dev server that is yet another working area,
but I have a cron job that runs cvs update on it every 5 minutes:
0,5,10,15,20,25,30,35,40,45,50,55 * * * * (for dir in elements3; do cd
/export/home/u/willer/$dir; nice /usr/local/bin/cvs update -dP 2>&1
|grep -v '^[?MUP]' |grep -v 'Updating'; done)
(all on one line).
The designers do their stuff on their own hard drive, and use WinCVS
(www.wincvs.org) to commit changes. They preview the files as local files,
which works well enough for most purposes.
Also, the dynamic files (in my case HTML::Embperl files) have a .html
extension. This facilitates local-file preview.
