Re^3: Professional development with Perl

You import that as well - and SVN can give you a new version from the author, with your custom code ...

You have obviously not used SVN's merging tools. While very nice when they work, they often don't work, requiring a lot of hand-merging. Frankly, it's much better just to use the CPAN shell to install the version you want to install. Most of the time, installing the latest and greatest will be good enough.

I was thinking along the lines of having an older machine with OS that client has (FreeBSD or Linux in 99.99% cases) to compile the code myself ...

Assuming you're running the same Perl version. 5.6 and 5.8 are NOT XS-compatible. This means that something compiled against 5.6 will NOT run with 5.8 and vice-versa. 5.10 is rumored to be XS-incompatible with 5.8. The solution you're looking for is a list of prerequisites that you (or the client) install on the client machine. Period. Anything else is asking for more trouble than you want to deal with.

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Comment on Re^3: Professional development with Perl - how it's done?

Replies are listed 'Best First'.
Re^4: Professional development with Perl - how it's done? by adrianh (Chancellor) on May 30, 2006 at 12:05 UTC
You have obviously not used SVN's merging tools. While very nice when they work, they often don't work, requiring a lot of hand-merging. The wonderful SVK can help a lot there. Frankly, it's much better just to use the CPAN shell to install the version you want to install. Most of the time, installing the latest and greatest will be good enough. I prefer having my dependencies under source control outside of CPAN. Makes integrating them with the rest of my build much easier, and helps those occasions that aren't "most of the time" become less painful.	[reply]
Re^5: Professional development with Perl - how it's done? by dragonchild (Archbishop) on May 30, 2006 at 14:02 UTC
I use SVK - while better than SVN, that's not saying much it still has issues Incompatible changes still have to be merged by hand. Some CPAN modules may change a couple lines a release. Then, there's modules like DBM::Deep that will add and remove whole files and those that stay will be significantly changed, even though the API and behavior that you care about hasn't changed at all. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^6: Professional development with Perl - how it's done? by adrianh (Chancellor) on Jun 13, 2006 at 12:01 UTC
that's not saying much Well personally I think svk's merge support is significantly better than SVNs. I find the trivial handling of mirrors and remote branches/merges a joy. it still has issues Yup... I do hit snags occasionally. Very occasionally though. Incompatible changes still have to be merged by hand. True - but that's always going to be necessary. Some CPAN modules may change a couple lines a release. Then, there's modules like DBM::Deep that will add and remove whole files and those that stay will be significantly changed, even though the API and behavior that you care about hasn't changed at all. All true - and I still prefer to have all the dependencies for my build in source control so I can figure out those changes if/when they cause problems.	[reply]