Perl code, RCS/CVS, and distribution

[Masem]

I'm at the point in my perl coding that I really think that I need to start using RCS/CVS more; I generally make archive backups, but a RCS would probably make more sense in what I'm doing of late. Additionally, I've just gotten my CPAN account set up and want to start putting some of the utility modules I've posted here to it, but I want the ability to make these updates easy. Even though I'm working by myself on these projects (and for fun), I figure that RCS'ing it cannot hurt.

I've had some experience with RCS before, but mostly though C/C++ programs; I know that things that you haven't checked out could be easily handled by the makefile (you'd got something like "source.c,v" from the RCS directory), but with perl, things are a little different; say I'm developing Module A and Module B; both have sufficiently different functionalities as to be distributed separately, but B relies on A. As to prevent pollution of the installed perl base, these modules are all developed in a user directory. So say I'm working on B, and all aspects of module A have been checked in, such that there is no reference to A in the @INC; is there a way to have perl or RCS or whatever be able to grab a copy of A from the repository and use that as opposed to having to check out a copy of A for testing of B? I would think that here, again, I could use a makefile, and do "make perlrun", which simply launches the perl code I'm testing, using appropriate rules to point to a RCS copy of A, but this seems overkill, somewhat.

In relation to this, I've looked at many of the code blocks for modules here and notice the typical indicators of RCS-inserted data ("$data$") for versions, dates, changes, and so forth, which makes perfect sense. But the format of the initial code block that usually precedes the code is quite different. Is there an accepted format, or should it just be consistent with other modules that I may write ?

---

Dr. Michael K. Neylon - [e-mail] || "You've left the lens cap of your mind on again, Pinky" - The Brain

[DrZaius]

You're not using CVS?? I find CVS to 'scale' a lot better, especially when your code gets multiple developers.

You are using h2xs, right? You are using it to make test cases and to install your code properly, right?

At work we use our cvs server for our modules. There is a CVS module called modules (man, that's confusing). In there, we use h2xs, but instead of leaving the directories as Module/Name (for a module called Module::Name), we move it to Module-Name. This prevents "is Module::Name::Alpha a parent or a child?"

So, if you did a cvs co modules you would get a directory structure like this:

modules/Module-Name
modules/DBIx-DSN
modules/XML-Serialized

When you are testing modules, try perl Makefile.pl PREFIX=~/perltest and include that directory in any scripts you use.

cheers.

[knight]

An alternative is the Aegis change management system. Aegis uses a very different model than CVS, although it can be configured to use RCS as its underlying source code control system, in much the same way that CVS wraps the RCS functionality. Aegis manages and enforces testing conventions in very much the way you describe--that is, it can run tests with references to copies of things already checked in to the repository. It does more for you, although you have to buy into its model of the development cycle. If you do, though, it's very powerful.

Setting up Aegis for Perl module development is a little tricky, but a solved problem. (Recently, Michael G. Schwern has started using it for module development.) I'd be happy to assist anyone who wants to give it a try.

[bikeNomad]

If you use CVS, you'll always have a copy of your modules around to use. CVS also does not require preemptive locking, which I've found to be a more natural way to work.

[enoch]

    I am not sure I understand what you are trying to do. We use CVS where I work, and we make build scripts for all of our products. The build scripts basically checkout any necessary source code from CVS, and copy them to appropriate locations. A build script sorta like this:

rm -rf /path/to/development/projectA
rm -rf /path/to/development/projectB
rm -rf /usr/lib/libsUsedInProjects
cvs checkout projectA
rm -rf ./projectA/CVS  # delete CVS dir
mv ./projectA/ /path/to/development/
cvs checkout projectB
rm -rf ./projectB/CVS  # delete CVS dir
mv ./projectB/ /path/to/development/
cvs checkout projectLibs
rm -rf ./projectLibs/CVS  # delete CVS dir
mv ./projectLibs/* /usr/lib/

    Why is it that you do not want to have to checkout a copy of moduleA to test moduleB? Why would you want to utilize the "marked-up" copy in the repository?

Jeremy

[buckaduck]

Maybe I'm misunderstanding the question. Can't you do something like ci -u filename and have the module still available after checkin?

buckaduck