On Mar 6, 2006, at 4:10 AM, Nik Clayton wrote:
Matisse Enzer wrote:
Currently we are evaluating these options:
1) Maintain a list of the .tar.gz files and install from CPAN,
for example M/MA/MATISSE/Text-TagTemplate-1.8.tar.gz
2) Put the CPAN .tar.gz files in a local CPAN repository a
Matisse Enzer wrote:
Currently we are evaluating these options:
1) Maintain a list of the .tar.gz files and install from CPAN,
for example M/MA/MATISSE/Text-TagTemplate-1.8.tar.gz
2) Put the CPAN .tar.gz files in a local CPAN repository and use
CPAN::Site to install - that way we
I did some experimenting yesterday with CPAN::Mini::Inject and our
Subversion repository:
As many of you know, in the Subversion source control system every
file has a URL - it can be a file:// url, an http:// URL, an svn://
URL, etc.
I think what will work well for us is to use CPAN::Mi
Michael Peters writes:
> Krang keeps a local copy of all of the CPAN modules it uses in it's
> source repo. Also, each module is installed locally to krang so that
> it can be installed without affecting an existing installation. ...
We've used software that does things like that; I think the OT
On Tue, February 28, 2006 12:35 am, Steffen Mueller wrote:
> The upside is that it might be using less bandwidth in the long run.
For us bandwidth is not at all an issue.
> You might want to look at
> http://search.cpan.org/~rjbs/CPAN-Mini-0.40/lib/CPAN/Mini.pm and
> possibly
> http://search.cpa
On Mon, February 27, 2006 8:14 pm, Dr Bean wrote:
> There is some interesting advice in the subversion book.
>
>Linkname: Vendor branches
> URL:
>
> http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html#svn.advanced.vendorbr.general
I've read this section and i
Matisse Enzer wrote:
>
> On Feb 27, 2006, at 6:59 PM, Tyler MacDonald wrote:
>
>> #3 seems like the lowest maintenence. Maintaining on a .tar.gz in CVS
>> seems easier than integrating diffs of the newest version whenever
>> you want
>> to upgrade.
>>
>
> We definitely do NOT want to be i
Matisse Enzer wrote:
#2 has it's benefits too - you could even mirror all of CPAN, and
just maintain a script with "install" commands to install the
versions you
want;
install "KWILLIAMS/Module-Build-0.27_04.tar.gz";
etc. That makes both upgrading easy and makes your build proces
On Feb 27, 2006, at 6:59 PM, Tyler MacDonald wrote:
#3 seems like the lowest maintenence. Maintaining on a .tar.gz in CVS
seems easier than integrating diffs of the newest version whenever
you want
to upgrade.
We definitely do NOT want to be integrating diffs if we can avoid it.
If
On Feb 27, 2006, at 8:14 PM, Dr Bean wrote:
There is some interesting advice in the subversion book.
Linkname: Vendor branches
URL:
http://svnbook.red-bean.com/nightly/en/
svn.advanced.vendorbr.html#svn.advanced.vendorbr.general
Thanks - that looks interesting, although complica
On Mon, 27 Feb 2006, Matisse Enzer wrote:
> I'm helping plan inmprovements to a build & deploy system and am
> wondering what people think is the "best practice" for handling
> version control of locally-installed CPAN modules.
> 3) Put the .tar.gz files in our source-code control system, and
Hello Matisse,
I like these two ideas:
Matisse Enzer <[EMAIL PROTECTED]> wrote:
> 2) Put the CPAN .tar.gz files in a local CPAN repository and use
> CPAN::Site to install - that way we *only* get the versions in
> our local CPAN repository and dependencies are managed by the
>
12 matches
Mail list logo
