Meeting: Tuesday 27th July

[Peter Edwards]

Hi, interesting post.
I think Subversion works better for a small team in one place than git. As
soon as you have remote workers, though, or more branching then I think git
makes more sense.
I helped the team here moved from CVS to Subversion over the last year.
Sometimes it's easy to forget how much better than CVS svn is!
The Beeb has relented a bit on Perl and is setting up a CI server for Perl
apps as part of its new "Platform" (was called Forge) and that includes
using cpanminus and local::lib to handle multiple versioned libraries. It
seems like a sensible and efficient way of managing things.
In our bit we use local::lib to bundle app-specific library distributions
and then with the same O/S versions we can rsync them around. It's also
handy for adding a particular version of an XML parser, say, for a specific
use case for a feed.

Cheers, Peter

On 28 July 2010 08:38, Tom Hukins <tom at eborcom.com> wrote:

> Rod and I discussed the various version control systems that our
> workplaces use and want to migrate to.  We're both looking forward to
> moving to distributed version control systems from Subversion, which
> we both considered "CVS done better" as opposed to "version control
> done properly" as many others have observed before.
>
> We both felt the name "distributed version control" misses the best
> feature that such products have:  they serve as "self contained
> version control systems" so everything from the repository lives in
> your working copy.  Consequently, they let you play around more with
> your code before pushing it to a server.
>
> JJ told me about cpanminus, which I'd heard a bit about before as a
> replacement for Perl's venerable CPAN client.  I'm going to try it out
> today as JJ tells me it runs faster:  instead of parsing CPAN's list
> of distributions it contacts a server over the network to figure out
> what to install.
>
> It's just occurred to me that I've described one tool that uses the
> network to offload local processing and one that uses local resources
> to provide more flexibility.  I guess there's still more than one way
> to do it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/miltonkeynes-pm/attachments/20100728/2ae7695e/attachment.html>