[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PHP/script-based CVS?

From: Pierre Asselin
Subject: Re: PHP/script-based CVS?
Date: Sat, 18 Nov 2006 21:16:20 +0000 (UTC)
User-agent: tin/1.6.2-20030910 ("Pabbay") (UNIX) (NetBSD/3.1_RC3 (i386))

address@hidden wrote:
> Pierre Asselin wrote:
> >
> > Question: do the developers run their own private instance of the
> > web server ?  It's easier if they do.
> >
> No -- many of the staff aren't web developers, just program managers
> doing text updates through a WYSIWYG editor, and don't run web servers
> on their machines. Also, we use interpreted scripting languages (Cold
> Fusion, PHP) so there hasn't been a compelling reason to run a web
> server locally: we have a remote dev server for all our development
> work, which then goes to pub.

OK, that might do.

> Why do you ask?

To make sure the people making the changes have a way to validate
them without uploading their changes to the development website.
It seems that they do.

What I would recomment is to run the development web server
off a checked-out CVS sandbox of the website.  (The CVS/
subdirectories shouldn't be a problem because the web server
will just ignore them.)  You then set up a loginfo hook
to update the sandbox whenever someone commits a file,

The staff can check out the website files to their box and edit
their private copies.  When they're done, they commit their changes
and the dev sandbox is automatically updated.  If two people have
been editing the same file one of them will get the usual complaint
about needing to update first.  You have to make sure that their
tools play nicely with other programs, e.g. don't keep files open
read-write on Windows and block CVS' attempt to update the disk
copy.  Your people may need to save and close the file before
committing.  In general the tools have to stay out of your way
instead of enforcing their single solution.  That's fundamental,
because it's their single solution that you don't like.

One problem is conflicts markers.  They are sure to confuse
any WYSIWYG tool.  Your users have to be able to go in the source
window and edit the raw html if that happens.

Also, the tools have to play nicely with revision control systems
in general.  For example, a small edit should result in a small
diff.  IIRC Dreamweaver is meets that criterion.

You should probably define subsets of the web site in your
CVSROOT/modules so the staff members don't have to check out the
whole thing.

> I would really like to not have to deploy and maintain a bunch of
> server instances if at all possible.

Hmmm, it's been a few years since I've been in this business, but
what we used to do is run multiple instances, one per staff, of
the same web server binary on the dev machine.  Each instance ran
off a CVS sandbox and was configured to listen on a different
nonstandard port.  For example I would browse to http://devserver:9080
to see my instance.  I don't remember how we customized the
ports but it wasn't hard.  Every developer knows how to restart
his instance when necessary.

Then your staff can dreamweave/ftp/lock/whatever to their private
sandbox on the dev server.  They download and upload their files
exactly as they do now, except there is never a lock conflict
because the upload destination is their private copy.  After
uploading, they can sanity-check the results by browsing their
instance.  To publish their changes, they commit.  They have to
learn how to run cvs commit from the dev server, but that's not
the hardest thing to do.

This solution is easier on the tools but uses more disk on the
server.  It also saves you from installing and maintaining
CVS client on the staff machines (but that's not so hard).
The biggest issue is still training your staff to handle
merge conflicts.

pa at panix dot com

reply via email to

[Prev in Thread] Current Thread [Next in Thread]