[sf-perl] Thanks for coming to the meeting

[Earl Ruby]

Jeffery:

Enjoyed the talk.

At the company I currently work for we have to ensure that all of the
CPAN module versions installed on 80+ servers are known and tested
versions. Our internal code is not packaged up using CPAN-style
packaging, we only use CPAN repos for distributing CPAN modules. Our
use case is a little simpler than yours, so we just keep the entire
CPAN repo rsync'ed to a "/cpan/latest" directory, and we have a
locked-in-time "/cpan/production" repo that's been tested and is used
by all production servers.

When we want to test the latest modules against our code we make a
release candidate (rc) using hard links:

cp -al /cpan/latest /cpan/rc-20120301235615

Take a set of test servers, tell them to use /cpan/rc-20120301235615
as their CPAN repo, run all tests, verify that all is well, then:

mv /cpan/production /cpan/production-archive-20120302030122
mv  /cpan/rc-20120301235615 /cpan/production

Now all servers pull the latest CPAN files from production. If
something goes Terribly Wrong, move the old production repo back into
place.

If someone wants a special repo for qa or dev they can easily create
one with hard links:

cp -al /cpan/latest /cpan/qa-20120301235615
cp -al /cpan/latest /cpan/dev-20120301235615

Hard links have the advantage of only using an extra inode on the file
system to make a copy of the file, but when /cpan/latest is updated
the rc, qa, and dev hard links still point to the old versions of the
files. If someone wants to modify their hard-linked CPAN "dev" copy"
their changes don't affect the other copies of the repos, and the only
additional storage hit is for the changed files, not the whole repo.

You'd mentioned that you wanted to offer a way to maintain separate
qa, dev, etc. repos. You might take a look at using hard links and see
if they give you the functionality you want.

One word of warning, depending on the file system you're using you may
want to create extra inodes when you format the file system. I
typically use ext3 and I add extra inodes when I create the file
system. ext4 is supposed to add extra inodes as needed, but I've
stayed away from ext4 due to performance issues. YMMV.

-- Earl

On Wed, Feb 29, 2012 at 12:15 AM, Jeffrey Thalhammer
<jeff at imaginative-software.com> wrote:
> Hi everyone-
>
> I just wanted to thank all of you who came out for the PM meeting tonight.  I really enjoyed speaking with you, and I hope you found the presentation on Pinto informative.  I'll let you know when I've posted the slides to Slideshare.
>
> I'll be presenting Pinto to LA.PM next month and again at YAPC in June.  So if you have any feedback that would help me make the presentation better, I'd love hear from you.
>
> Lastly, if you see an opportunity for Pinto to help your team manage their dependencies, I'd be happy to provide you with some consulting services in that area.  You can reach me via jeff at imaginative-software.com or 415-215-2834.
>
> Special thanks to Fred Moyer for organizing and Mother Jones for hosting too.
>
> Cheers!
>
> -Jeff
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm



-- 
Earl Ruby
http://earlruby.org/
@earlruby