perl Makefile.PL /dev/null works for us. We encapsulate it in a
macro (see below).
Now why didn't I think of that? :). This works nicely. We still ahve to
patch some of the individual Makefile.PL's, but that is acceptable (some
of them have exit; at the end of them for example which causes
I find not only amazing that so many of us are doing the exact same
thing, but also that the project I'm working on now is about these same
ideas we have. So, why not make it GPL?
I'm developing an intranet to organize a web development team and there
is a lot of CVS involved in it. Right now
Michael Schout writes:
example, one time we upgraded Apache::Filter between releases.
Unfortunately, the old version was not compatible with the new version,
so a single machine could run either the current release branch, or the
development branch, but not both simultaneously (because
From: Steven Lembark [EMAIL PROTECTED]
One quick way to deal with testing things is to tag the releases
with something meaningful and pass the tag to Q/A. They do an
update -d -P -r yourtag and test it. If things work then the update
gets run again in production and life goes on. Since
Okay, I'll chime in on this one.
I work on a medium sized mod_perl project (approximately 50,000 lines of
perl code). This project is managed similarly to to the setups that
have been described so far. We store all of our CPAN module sources in
CVS, and currently we distribute the modules to
Rob Nagler wrote:
Another approach which allows easy sharing between projects is:
~/src/perl/
+ Project1/
+ Project2/
+ Project3/
where Project[123] are root package names. Set PERLLIB=~/src/perl and
you can get access to any *.pm in the system, each has a globally
unique name.
Hi Dom --
How do you cope with the problem that perl has of running different
versions of modules?
We have a similiar situation, in that we're running several projects
with different sets of perl libraries. We have common code between
them. The trouble starts when we're running several
At 8:27 AM -0500 11/1/02, Jesse Erlbaum wrote:
Hi Dom --
How do you cope with the problem that perl has of running different
versions of modules?
We have a similiar situation, in that we're running several projects
with different sets of perl libraries. We have common code between
them.
Hi Ray --
Jesse are you saying that you have a single apache server running
multiple vhosts with different versions of the same module loaded for
different vhosts? Is that actually possible?
I thought that whenever you first require ModuleX it will use the
value of PERL5LIB in that context
Dominic Mitchell writes:
How do you cope with the problem that perl has of running different
versions of modules?
Actually, we have two problems. One problem is developing with
multiple versions and the other is what you mention, running
production systems.
Sometimes I might be in the middle
Hey Rob --
Oh, and we *never* (almost :-) put code in programs. The programs
invoke a *.pm file's main so we can say bla-some-command and always
get the right version.
This is how CGI::Application works, too. You might want to check it out!
For the benefit of those who are not yet putting
Ged Haywood wrote:
Hi all,
On Thu, 31 Oct 2002, Iain 'Spoon' Truskett wrote:
experimenting with perforce [which, so far, appears nicer than CVS] )
Yikes! Josh, you got anything to say about that?
Well I have used perforce much more than CVS now, so that is where
I'm most comfortable.
Oh, CVS is free which is always a good thing. :)
subversion (http://subversion.tigris.org/) has been gaining lots of
momentum lately, and I just saw this link today:
http://svnbook.red-bean.com/
some of you might know the folks at red-bean from their other
projects, like
Hi all,
On Thu, 31 Oct 2002, Iain 'Spoon' Truskett wrote:
experimenting with perforce [which, so far, appears nicer than CVS] )
Yikes! Josh, you got anything to say about that?
73,
Ged.
Another approach which allows easy sharing between projects is:
~/src/perl/
+ Project1/
+ Project2/
+ Project3/
where Project[123] are root package names. Set PERLLIB=~/src/perl and
you can get access to any *.pm in the system, each has a globally
unique name. This makes it easy
On Wed, 30 Oct 2002 [EMAIL PROTECTED] wrote:
I don't believe in transfering _any_ binaries around,
every binary recompiles on its new platform at install
time. All modules, apache, external software etc. This
eliminates those pesky little problems that pop up when
you start pushing binaries.
On Wed, 30 Oct 2002, Bill Moseley wrote:
At 04:47 PM 10/30/02 -0500, Jesse Erlbaum wrote:
Web development projects can map very nicely into CVS. We have a very
mature layout for all web projects. In a nutshell, it boils down to this:
project/
+ apache/
+ bin/
That
I dont really understand where you are coming from, its
easy enough for the script to recompile its external
dependancies on install. This way I don't really care what
core version of linux or solaris or BSD is installed on
each platform since we do not control them all.
Precisely _because_
On Thu, 31 Oct 2002 [EMAIL PROTECTED] wrote:
[...]
I guess in your book we suck either way eh? Life goes on
:)
You'll change your ways when you get more servers. :-)
It's not easy enough for the script to do anything if the base
system installations are not very similar. If they are; then
Does anyone in the list use any kind of version control (e.g. CVS) for
the perl/template codebase of their website?
Now that my code base is growing I feel the increasing need to provide
better version/backup control than my current hourly crontab tar.
I don't however feel that the
We felt the same way but once we went to CVS we never
looked back and can not imagine going with out source
control. It may seem like the web doesnt fit that paradigm
but if you break your modules up properly it works like a
champ.
We broke out into 'html','components',
]
cc:
Subject: [OTish] Version Control
your purpose?
Chang-Ping Hsiao
-Original Message-
From: Richard Clarke [mailto:ric;likewhoa.com]
Sent: Wednesday, October 30, 2002 1:09 PM
To: [EMAIL PROTECTED]
Subject: [OTish] Version Control?
Does anyone in the list use any kind of version control (e.g. CVS) for
the perl/template
, Chang-Ping [mailto:CHsiao;corp.untd.com]
Sent: Wednesday, October 30, 2002 4:29 PM
To: 'Richard Clarke'; [EMAIL PROTECTED]
Subject: RE: [OTish] Version Control?
CVS is easy to use but confusing at first.
Once you get used to it, you should not complain.
I don't quite get your saying I
into each
other? it
seems like CVS would work well if everyone was developing
on his/her own
box.
Nate
-Original Message-
From: Hsiao, Chang-Ping [mailto:CHsiao;corp.untd.com]
Sent: Wednesday, October 30, 2002 4:29 PM
To: 'Richard Clarke'; [EMAIL PROTECTED]
Subject: RE: [OTish] Version Control
John,
[EMAIL PROTECTED] wrote:
We felt the same way but once we went to CVS we never looked back and
can not imagine going with out source control. It may seem like the
web doesnt fit that paradigm but if you break your modules up properly
it works like a champ.
We broke out into
Hi Richard --
Does anyone in the list use any kind of version control (e.g. CVS) for
the perl/template codebase of their website?
Every time! My team has been developing web sites with CVS for years now.
I can't imagine doing a web project without it! It would be like.. Oh...
Skydiving
We use CVS to do in-place upgrades on the live system for
smaller updates.
For the big stuff we bring the boxes out of their pools
one at a time and upgrade them.
In both cases, the worse case is that a user might see two
versions of the same page in the span of 60 seconds if
they catch us
Hi Richard --
Do you use CVS checkouts to upgrade the live system or do you this
manually. i.e. stop apache, tar and remove old code, untar new code,
start apache et voila?
On single-server web sites (as opposed to a site running in a clustered
environment) a CVS checkout works just fine.
Hsiao, Chang-Ping wrote:
CVS is easy to use but confusing at first.
This could be the root of my reservations.
Once you get used to it, you should not complain.
I don't quite get your saying I don't however feel that the organizational
logic of a websites code base fits well into the CVS
On Oct 30 Richard Clarke wrote:
Does anyone in the list use any kind of version control (e.g. CVS) for
the perl/template codebase of their website?
Using cvs, I'm not sure of an elegant way to update. I'm worried about
CVS subdirectories sitting under htdocs, to be specific.
Perhaps I just
Hear hear!
We're using AxKit for our development and everyone has a copy of the
entire site (many thousand files) in their home directories on the
development machine and its been great! No more I didn't touch it but
it stopped working problems :) It also allows everyone to experiment
with
Jim Martinez wrote:
On Oct 30 Richard Clarke wrote:
Does anyone in the list use any kind of version control (e.g. CVS) for
the perl/template codebase of their website?
Using cvs, I'm not sure of an elegant way to update. I'm worried about
CVS subdirectories sitting under htdocs, to
Hey Jim --
Also, Randal Schwartz wrote about cvs is a slightly more general setting:
http://www.linux-mag.com/2002-07/perl_01.html
The system we use goes a bit beyond even what Randal describes (although, he
is on a similar track).
In a nutshell, the Apache httpd.conf file is templatized to
Hey Jim --
Also, Randal Schwartz wrote about cvs is a slightly more general
setting:
http://www.linux-mag.com/2002-07/perl_01.html
The system we use goes a bit beyond even what Randal describes (although,
he
is on a similar track).
In a nutshell, the Apache httpd.conf file is
Who needs network guys, reverse pop the ssh tunnel ;)
I find it amazing that so many of us are doing the exact
same thing in terms of managing our large site installs
yet its nowhere to be found in any FAQ, knowledge base or
general forum.
I know on our side we developed these solutions over
developing for an intranet, not deploying to external customers, so I have
a lot more control of the production server.
Wes Sheldahl
Jesse Erlbaum [EMAIL PROTECTED] on 10/30/2002 04:47:41 PM
To:[EMAIL PROTECTED]
cc:
Subject:RE: [OTish] Version Control?
small excerpt from original post
At 04:47 PM 10/30/02 -0500, Jesse Erlbaum wrote:
Web development projects can map very nicely into CVS. We have a very
mature layout for all web projects. In a nutshell, it boils down to this:
project/
+ apache/
+ bin/
That requires binary compatibility, though. I have a similar
Hi Richard --
Thanks for the extensive info,
I am curious Assuming your website is made up different sections,
would I be correct in assuming that the files this section depends on
are finite?
e.g.
bin/section_a.sh
cron/section_a.crontab
template/section_a.html
This could be the root of my reservations.
Why do you think people always talk about re-organize? :-)
Indeed, I don't get what I'm saying either.
My organisation is something like (slightly over-simplified),
_lib/Example/Control/section_a.pm
_lib/Example/Control/section_b.pm
We check in all of our perl modules into CVS and its a
_MAJOR_ life saver. Keeps everyone on the same path so to
speak.
I don't believe in transfering _any_ binaries around,
every binary recompiles on its new platform at install
time. All modules, apache, external software etc. This
Hi Wes --
I really like your approach, and appreciate your explanation. I'm
wondering
how you handle the packaging and installation; do you just use a shell
script to put the different pieces where they belong, or have you devised
something else?
Something else! Files don't get installed
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) [31 Oct 2002 09:47]:
[...]
I find it amazing that so many of us are doing the exact same thing in
terms of managing our large site installs yet its nowhere to be found
in any FAQ, knowledge base or general forum.
I suspect a lot of us are so used to
Hi Bill --
project/
+ apache/
+ bin/
That requires binary compatibility, though. I have a similar setup, but
the perl and Apache are built separately on the target machine since my
machines are linux and the production machine is Solaris.
Binary incompatibility is not a
At 03:21 PM 10/30/02 -0800, [EMAIL PROTECTED] wrote:
We check in all of our perl modules into CVS and its a
_MAJOR_ life saver. Keeps everyone on the same path so to
speak.
I think I confused two different things: perl module source vs. installed
modules. Do you check in the source or the
Richard == Richard Clarke [EMAIL PROTECTED] writes:
Richard Does anyone in the list use any kind of version control (e.g. CVS) for
Richard the perl/template codebase of their website?
Yup. Even wrote a column about it:
http://www.stonehenge.com/merlyn/LinuxMag/col38.html
--
Randal L.
46 matches
Mail list logo
