Re: [OTish] Version Control?

[Michael Schout]

Okay, I'll chime in on this one.

I work on a medium sized mod_perl project (approximately 50,000 lines of perl code). This project is managed similarly to to the setups that have been described so far. We store all of our CPAN module sources in CVS, and currently we distribute the modules to the servers via RPM. Its critical that we maintian sources to the CPAN modules in CVS because some modules have to be patched to make the modules work for this particular project (and some modules just plain have bugs :)). The modules get installed in the main perl directory (e.g.: /usr/lib/perl5).

We use cvs branches to manage releases and development versions of the web site and perl code. When we get to a realease point we make a branch (e.g.: RELEASE-1_0), and html developers continue working on that branch for changes to the currently released site. The web servers can be updated with simply "cvs update" this way.

On the main trunk perl/web development continues until the next release happens. However, due to the fact that the CPAN modules are distributed via RPM, there are various incompatibility problems that come up. For example, one time we upgraded Apache::Filter between releases. Unfortunately, the old version was not compatible with the new version, so a single machine could run either the current release branch, or the development branch, but not both simultaneously (because Apache::Filter was incomptaible and was installed under /usr/lib/perl5).

So currently we are looking into also installing CPAN modules under the project directory and managing the binary CPAN modules CVS, which would solve this problem. Developers could check out a sandbox of the release branch and they would get the modules that belong to that release (binary compatibility is okay because our development machines match the production machines).

The management nightmare to all of this is that automating the build process for lots of CPAN modules (rougly 110 of them) is painful. Our CPAN source tree looks something like this:

project-support/
src/
Makefile
Apache-Filter/
CGI/
Digest-MD5/
...

First we tried making a Makefile.PL in "src" that used the DIR attribute of WriteMakefile to specify the subdirs to build all of the modules. THis didnt work so well. The problems with this are:

1) some Makefile.PL's refuse to generate a Makefile if PREREQ_PM's are not satisfied (if we haven't built them yet)
2) some Makefile.PL's are INTERACTIVE, and you cant turn it off (e.g.: Apache::Filter requires you to hit <Return> a number of times at a MINIMUM.

So we resorted to a set of overly-complicated GNUmakefiles that would generate Makefile's from Makefile.PL's, and these would set PERL5LIB to find the dependencies (e.g.: DBD-Pg would put ../DBI/blib into PERL5LIB).

I'm not convinced this is the best way to go about it, but it "sort of" works.

How does everyone else cope with this (managing trees of CPAN modules / CPAN module tree build environments)? Maybe we are sort of unique in that we use so many 3rd part CPAN modules, but because we use so many of them its pretty critical that we manage them in CVS.

Mike