ess can take of resolving
dependencies. The downside is having yet-another-repository.
Whatever we do we would like to have a single-step build and release
process:
./build_script.pl --build-number=20060227-001 --environment=QA
and that will deploy both our code AND the CPAN modules we us
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
>
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 module
Ovid wrote:
> Hi all,
>
> I'm not proposing to write a Test::SQL module, but I am tired of having
> the following two things not being equivalent:
>
> CREATE TABLE foo (
> id INTEGER NOT NULL PRIMARY KEY,
> name VARCHAR(32) NOT NULL,
> title
> age INTEGER
> );
>
Hi all,
I'm not proposing to write a Test::SQL module, but I am tired of having
the following two things not being equivalent:
CREATE TABLE foo (
id INTEGER NOT NULL PRIMARY KEY,
name VARCHAR(32) NOT NULL,
title
age INTEGER
);
And:
create table foo (
id
