Standard practice seems to be to install the modules to a location somewhere in your perl's @INC and then just let the programs which use them find them there rather than designating a specific path, either local or centralized. This is, obviously, a variation on "shared".
Regardless of which layout you go with, source control is very highly recommended. svn and cvs are good, reliable solutions for distributed source control, both of which are well-known, widely-used, and can be installed for free on as many machines as needed. If the lack of source control is due to resistance from other developers, you can even install either of them on your local machine to create your own private repository without disturbing anyone else who may think of it as "more trouble than it's worth". | [reply]
[d/l]
[select] |
Suppose I use the shared or @INC path... Does source control really help in that case? It may help me with my private development, but when I release, I will have a global effect. (Fixing what ain't broken.)
| [reply] |
Source control becomes vastly more helpful when sharing modules between projects - if you break another project, source control is what will let you quickly and easily roll back the problematic changes (or just show you what all the changes are so that you can figure out why it broke the other project and find a way to make them both work).
The other tool which becomes much more important for shared modules is a good set of automated test programs. (The Test::* modules from CPAN are the most common way of doing this in the Perl world, but a set of toy test apps can work just as well.) With good tests which cover all documented behaviour of the module, you can be reasonably certain you won't break other projects by verifying that your test results are the same before and after any changes. (Aside from the results of new tests added to verify that the changes themselves work correctly, of course.)
| [reply] |
Using a central repository for common code makes too much sense, especially as you are refactoring anyway. Cut and paste can lead to dozens or hundreds of almost like scripts, customized in unique ways for unique circumstances. It will always be easier to manage a single set of libraries whose differences are driven by a configuration file than it will to have hundreds of unique-but-almost-alike scripts whose differences are probably unknown.
And if location Z must have some unique code, that location can still inherit modules from the main repository.
| [reply] |
Hi,
I have stupid fat fingers and a stupid fat brain
to go with them. Source control is vital when I'm
involved, and I know loads of programmers like me.
I had to be forced to use it, now I wouldn't be without it.
Source control can take a lot of the heart-ache out
of major developments.
J.C.
| [reply] |
How does source control work with shared modules? I don't yet see the light.
| [reply] |