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
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
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
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 process
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 integrating
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 it
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
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.
We have a bunch of code in version control (CVS now, moving to SVN soon)
We also have a large number of CPAN modules
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
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
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
11 matches
Mail list logo
