Re: Distributing the CPAN

2010-04-03 Thread Tim Bunce
On Fri, Apr 02, 2010 at 04:49:44PM +0200, Aristotle Pagaltzis wrote: > * Tim Bunce [2010-04-02 15:55]: > > So, for a cpan-git-mirror to update itself it only needs to do: > > > > cd cpan-all && git pull && git submodule update > > > > The git pull of cpan-all repro would be very fast as it's t

Re: Distributing the CPAN

2010-04-03 Thread Ask Bjørn Hansen
On Apr 2, 2010, at 14:03, Tim Bunce wrote: > Imagine a cpan-all 'superproject' repro that has all the distros as > submodules. This repro would be tiny when cloned because it only > contains empty directories for the distos plus the metadata for where > the upstream distro repro lives and what t

Re: Distributing the CPAN

2010-04-02 Thread Aristotle Pagaltzis
* Tim Bunce [2010-04-02 15:55]: > So, for a cpan-git-mirror to update itself it only needs to do: > > cd cpan-all && git pull && git submodule update > > The git pull of cpan-all repro would be very fast as it's tiny. With 15,000(?) distributions = submodules = directories, it’s not *that* ti

Re: Distributing the CPAN

2010-04-02 Thread Ask Bjørn Hansen
On Apr 1, 2010, at 16:50, Tim Bunce wrote: > * The need for widespread mirroring is less significant than it was in > years past. (Also using git as the inter-mirror transport of source files > means there'll be much less traffic between mirrors. Effectively only > the diffs between releases.) T

Re: Distributing the CPAN

2010-04-02 Thread Tim Bunce
On Fri, Apr 02, 2010 at 01:16:58AM +0200, Ask Bjørn Hansen wrote: > > On Apr 1, 2010, at 16:50, Tim Bunce wrote: > > > * The need for widespread mirroring is less significant than it was in > > years past. (Also using git as the inter-mirror transport of source files > > means there'll be much le

Re: Distributing the CPAN

2010-04-02 Thread Adam Kennedy
On Fri, Apr 2, 2010 at 4:11 AM, Michael G Schwern wrote: >> * The need for widespread mirroring is less significant than it was in >> years past. (Also using git as the inter-mirror transport of source files >> means there'll be much less traffic between mirrors. Effectively only >> the diffs betw

Re: Distributing the CPAN

2010-04-02 Thread Tim Bunce
On Thu, Apr 01, 2010 at 08:03:53PM +0300, Burak Gürsoy wrote: > > From: Tim Bunce [mailto:tim.bu...@gmail.com] On Behalf Of Tim Bunce > > Subject: Distributing the CPAN > > > * cpanminus already supports installing from a git repo. > > > * Over time the number of cpan-git-mirror's and cpan-git-se

Re: Distributing the CPAN

2010-04-02 Thread Michael G Schwern
On Thu, Apr 1, 2010 at 7:50 AM, Tim Bunce wrote: > On Thu, Apr 01, 2010 at 12:39:27AM -0400, David Nicol wrote: >> On Wed, Mar 31, 2010 at 7:43 AM, Ask Bjørn Hansen wrote: >> > The main point here is that we can't use 20 inodes per distribution. >> >> so don't. How much reengineering would be nee

Re: Distributing the CPAN

2010-04-01 Thread David E. Wheeler
On Apr 1, 2010, at 1:12 PM, Tim Bunce wrote: > Yes, I was envisaging something like gitPAN. Though if this took off > then moving the tarball->git import logic to the PAUSE server would > probably be a good idea. /me stashes these ideas away for PGAN…

Re: Distributing the CPAN

2010-04-01 Thread Arthur Corliss
On Thu, 1 Apr 2010, Tim Bunce wrote: Random thoughts... * If you squint a little you can view git as a database with excellent replication support. * cpanminus already supports installing from a git repo. * For backwards compatibility a simple perl web server could provide a classic CPAN http

RE: Distributing the CPAN

2010-04-01 Thread Burak Gürsoy
> -Original Message- > From: Tim Bunce [mailto:tim.bu...@gmail.com] On Behalf Of Tim Bunce > Sent: Thursday, April 01, 2010 5:51 PM > To: cpan-workers; module-authors@perl.org > Subject: Distributing the CPAN > * cpanminus already supports installing from a git repo. > > * Over time the

Re: Distributing the CPAN

2010-04-01 Thread Nicholas Clark
On Thu, Apr 01, 2010 at 03:50:49PM +0100, Tim Bunce wrote: > * The need for widespread mirroring is less significant than it was in > years past. (Also using git as the inter-mirror transport of source files > means there'll be much less traffic between mirrors. Effectively only > the diffs betwee