On Wed, 30 Oct 2002, Bill Moseley 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.
No, you don't need binary compatibility. You just need to design your system right and use the right tools. :-) With Perforce - http://www.perforce.com/ - you can map different directories in the repository to directories on the client with "client views". I have used that (Graham Barr came up with it there) so we could keep the binaries version controlled too. It's great. There we had all of our application software (including perl, apache, etc) distributed with perforce. With CVS or Subversion you could do something similar by setting up branches right or having a few symlinks. We had separate installations around the world serving different clients. Before we migrated from CVS to perforce we had a cvs tag for each installation, so rolling a new release was just o) make a new release number (r345), tag the files with that o) move the "installation tag" ("LosAngeles_Production" or "QA" or whatever) to the new release tag (r345). o) tell the servers to upgrade and restart the application. Perforce provides some features that makes it a bit neater, so the implementation was different but the concept the same. It worked (works actually) great. .... At another place we have a script to tag the files with a build number and then roll some tar balls. The tar balls then go to QA server and then to the production servers. There all the code is living on shared NFS servers, so rolling it out is just putting the code there and restarting the servers. Perl, Apache, etc are installed with rpms there. .... For a big project I like installing everything in /home/[project]/ - including perl, apache, mod_perl, ... - and having the whole directory version controlled. On the perl.org we have a bunch of smaller projects. There we use a shared /home/perl/ installation that gets distributed to the servers we use for production and for development. It has perl 5.8, various versions of Apache and other goodies. Each project (in /home/[project]/) then just reference that installation. Making it easy to setup a development environment on your own box is really really nice. On bigger projects I often even have several development environments installed at the same time, so I easily can work on different sub project or test different branches at the same time. [...] > Is anyone using cvs to manage updates made with web-based forms? The Twiki system and the Faq-O-Matic are using RCS on the backend to version control entries. - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
