On Sun, Mar 28, 2010 at 07:28:48AM -0700, dhu...@hudes.org wrote:
The danger in a CPAN::Mini and in removing old versions is that one is
assuming that the latest and greatest is the one to use. This is false.
And this is why I run cp5.6.2an.barnyard.co.uk etc.
It wouldn't be difficult for
On Sun, Mar 28, 2010 at 06:04:03PM -0400, David Golden wrote:
As always with perl, it depends. They are laid out just as a normal
CPAN repository, so if you have one in your urllist, something
specified as author/distribution.tar.gz might well resolve.
Not just might well resolve. It *will*
brian d foy wrote:
It's time for Spring cleaning again. If you have ancient versions of
modules sitting around in your PAUSE directory, consider letting them
retire to BackPAN (http://backpan.cpan.org). They don't disappear from
the world, but they don't inflate CPAN either. You don't have to do
On Tue, 30 Mar 2010, Matija Grabnar wrote:
Er, not exactly. Read
http://www.cvsup.org/howsofast.html
I had read http://www.cvsup.org/faq.html#features item #3.
From what I can see, cvsup uses the rsync algorithm on a file-by-file basis
(it uses just the differential send part of the rsync
On Tue, 30 Mar 2010, Rene Schickbauer wrote:
snip
This could work like any modern, distributed version control systems. That
way, the user would also be able to apply local patches and/or deciding which
changesets to pull in from the main server. Or have a complete, local mirror
and one for
On Sun, Mar 28, 2010 at 2:32 PM, Elaine Ashton eash...@mac.com wrote:
On Mar 28, 2010, at 12:48 PM, Randy Kobes wrote:
Has some sort of disk quota system for CPAN author accounts ever been
considered?
Not specifically, no, at least not that I'm aware of. That would have to be
