Hi, interesting post.<div>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.</div><div>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!</div>
<div>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.</div>
<div>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.<br>
<br></div><div>Cheers, Peter</div><div><br><div class="gmail_quote">On 28 July 2010 08:38, Tom Hukins <span dir="ltr"><<a href="mailto:tom@eborcom.com">tom@eborcom.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Rod and I discussed the various version control systems that our<br>
workplaces use and want to migrate to. We're both looking forward to<br>
moving to distributed version control systems from Subversion, which<br>
we both considered "CVS done better" as opposed to "version control<br>
done properly" as many others have observed before.<br>
<br>
We both felt the name "distributed version control" misses the best<br>
feature that such products have: they serve as "self contained<br>
version control systems" so everything from the repository lives in<br>
your working copy. Consequently, they let you play around more with<br>
your code before pushing it to a server.<br>
<br>
JJ told me about cpanminus, which I'd heard a bit about before as a<br>
replacement for Perl's venerable CPAN client. I'm going to try it out<br>
today as JJ tells me it runs faster: instead of parsing CPAN's list<br>
of distributions it contacts a server over the network to figure out<br>
what to install.<br>
<br>
It's just occurred to me that I've described one tool that uses the<br>
network to offload local processing and one that uses local resources<br>
to provide more flexibility. I guess there's still more than one way<br>
to do it.</blockquote></div></div>