in reply to putting perl and modules in your source code repository
We run the identical version of Perl with an identical set of CPAN modules on all our Unix boxes. I install this perl in the same well-known location on each of our boxes and adjust the PATH so that we use this version of Perl for all our work. We never use, or meddle with, the system /usr/bin/perl. We also ship our Perl distribution with all our products. Using the same (stable) Perl distribution everywhere avoids many annoying portability glitches ("it's easier to port a shell than a shell script").
To achieve this, I put the source tarballs for perl and all the CPAN modules on a shared drive available to all our Unix boxes, then run a script that builds perl from source (Configure, make, make test, make install), followed by building all the CPAN modules from source (perl Makefile.PL, make, make test, make install). The script contains an array of CPAN modules and builds them in the specified order. Because our Perl distribution must run on customer machines, and we don't want to meddle with their /usr/lib or /usr/local/lib, I have to take care to build any CPAN modules that depend on C libraries (e.g. XML-Parser) in such a way that they are wholly contained in our Perl distribution and don't depend on the contents of /usr/lib or /usr/local/lib. Only our build script is currently under version control. It would be easy to put all the tarballs under version control also -- and I probably should -- though I haven't bothered so far, mainly because they are essentially unchanged from the CPAN tarballs.
This scheme has worked reasonably well here because we require stability and repeatability (we typically update our Perl distribution only once every two years or so). One nuisance is when we need to make an emergency fix to a CPAN module. In that rare event, I unpack the CPAN module tarball, make the fix, then repack it into a new tarball with a different name, updating the build script to use the new tarball. Ugly. Since I've only needed to do this once, I haven't investigated a better way to deal with this use case. Ideas welcome. Notice that if you need to make an emergency fix like this, it's in your best interests to send the fix back to the module author as soon as possible, so as to get a proper code review and to avoid the long term burden of maintaining your own custom fork.
Though the above scheme has worked well for me here, it's probably not appropriate in a more volatile Perl environment, and I'm interested to hear how other folks deal with that.
Update: BTW, so as not to meddle with customer /usr/lib or /usr/local/lib (and to avoid the dreaded LD_LIBRARY_PATH, see also Re: Portable Perl?), I'm pretty sure our install script used to binary-edit our executables, replacing their artificially long build PATH with the customer chosen install directory (with our lib sub-directory appended).