I thought a good approach would be something like the following: Have a normal website that's pretty stable.
Have a dev site (cvs.euglug.org?) that contains the CVS web document root that the web team does development/changes on. Once we hit a solid 'release', or have debugged a new feature/change, we transfer that tree to the stable site (hopefully via a script). Once we get the new box set up, we can get the current site on CVS, alongside the current site in stable, and go from there. (This would be a CVS learning experience for me.) -Rob > On 20011130.1227, Bob Miller said ... > > Rob, if you could put the whole web site into a single directory tree, > including the Apache config files, then you could check that whole > tree into CVS. > > Then other people could create a clone of the site by doing something > like, > > export CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs > cvs get www > sudo httpd -d www > > and test new content on the clone by doing > > lynx http://localhost/ > (or netscape... (-: ) > > That way, everybody gets their own staging server. We could have CGI, > PHP, Python, etc. content on the site, and test it all before it goes > live. > > Bringing new content live on the web site would be a simple matter of > doing "cvs update" in the real web server's tree. You could do that > manually or make it happen automatically after a checkin.* > > The only bad bad part is that each of us would have to have an Apache > server with the right modules installed. > > Is this the direction you want to go? > > * TiVo's engineering web server does something similar. They have > a cron job that runs every five minutes updating the site from > the repository. > > -- > Bob Miller K<bob> > kbobsoft software consulting > http://kbobsoft.com [EMAIL PROTECTED] > > -- Rob <rob_at_euglug_dot_net> my @euglugCode = qw(v+++ e--- eug+ bsd+++ gnu+ S+++);
