On Mon, 2008-06-30 at 21:56 -0700, Jim White wrote:

> The idea that one software project that was X months behind another 
> active, successful project has somehow eliminated a feature and/or 
> performance gap is naive.   You would have to suppose that Mercurial 
> stood still while Bazaar addresses its most serious deficiency in the 
> comparison.
> 
> So as I say, given that Bazaar was convincingly inferior to Mercurial a 
> year ago, it now must prove it is either equivalent or superior now in 
> order to regard it is equal or superior.

The main factor here is the change of repository format in Bazaar.  As
the Mercurial people keep saying "Bazaar keeps changing the repository
format because they can't decide what to do".  What has happened of
course is that Bazaar is now using the same format as Git for speed.
The speed change with the Bazaar format change was pretty immense, and
they are still working on it.

So I would say all the performance differentials between Bazaar,
Mercurial and Git have changed.

> And you omitted what I consider my most relevant opinion in this 
> discussion, which is that it is far too early for the Groovy project to 
> seriously consider switching off of Subversion.
> 
> Not only are the DVCS client tools immature, what about the server-side? 
>   Besides the inevitable discovery of data reliability issues, there are 
> the web UI and issue tracking integration functions that have to be 
> dealt with too.

I think you are being over-conservative here.  If Sun, MySQL, Mozilla,
etc. can switch to a DVCS then there is no fundamental barrier stopping
Groovy.  Except one, Codehaus.  Your server-side point is critical here.
No Codehaus support means no change from Subversion for the central
master branch.  This doesn't stop individuals choosing better clients to
work with that central master branch.

> Maybe in a year (but more likely longer), the DVCS tools will be worth 
> switching to.  Moreover, folks who really do want to adapt to DVCS from 
> Subversion will be integrating the synchronization tools on the 
> server-side in order to preserve their Subversion repository (for it's 
> dependability and integration with other services) while satisfying the 
> clamor for DVCS.

I hope your forecast is too conservative.  Clearly a project cannot chop
and change infrastructureregualrly, so there must be no hasty decisions.
But it is good to have a roadmap.  This implies the sort of debate we
have been having.

In the end though for Groovy and Gant, it all depends on what Codehaus
do.  Until they have decided which DVCS to support all decision making
about switching to a DVCS is moot.   If they end up providing Bazaar,
Mercurial and Git, then we have a decision to make.

Subversion is a fine version filestore but compared to a DVCS it is
fundamentally inadequate for software development except where you have
one and only one branch and never need another branch.  This includes
Subversion 1.5.  If Groovy, Gant etc. never need more than one branch
then there is no need to even contemplate a move from Subversion.
However, I think that is not the case.  The "clamour for DVCS" is based
on a real workflow and function factors.
-- 
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077