« Return to Thread: should we use bazaar?
Re: should we use bazaar?
by Jim White
::
Rate this Message:
Jochen Theodorou wrote:
> Jim White schrieb:
...
>> Jochen Theodorou wrote:
>>
>> > ...
>> > (3) can explain why another tool is better
>>
>> I haven't done a direct comparison myself, but my impression so far is
>> that Mercurial is probably a better choice than Bazaar.
>>
>> If you consider that projects like OpenJDK, IcedTea, NetBeans, and
>> OpenSolaris have found it the current best choice for distributed
>> version control, then I'm sure you'd agree that at this point
>> alternatives would need to explain why they're better.
>
>
> I don't count that as argument. I would need to know why these projects
> chose Mercurial over Bazaar and if these reasons are still valid. On
> http://www.dribin.org/dave/blog/archives/2007/12/28/dvcs/ you can find:
>
> """
>> Historically, the main complaint about Bazaar has been it’s
>> performance. In fact, the main reason why OpenSolaris dismissed
>> Bazaar was due to poor performance. But that eval was a year ago,
>> which is essentially an eternity. Since then, Bazaar has hit 1.0 and
>> those performance criticisms have supposedly been addressed.
> """
>
> so I read performance was the main reason, and that one is not that
> valid anymore. ..
> http://opensolaris.org/os/community/tools/scm/bzr-eval/ suggests the same.
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.
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.
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.
Jim
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
> Jim White schrieb:
...
>> Jochen Theodorou wrote:
>>
>> > ...
>> > (3) can explain why another tool is better
>>
>> I haven't done a direct comparison myself, but my impression so far is
>> that Mercurial is probably a better choice than Bazaar.
>>
>> If you consider that projects like OpenJDK, IcedTea, NetBeans, and
>> OpenSolaris have found it the current best choice for distributed
>> version control, then I'm sure you'd agree that at this point
>> alternatives would need to explain why they're better.
>
>
> I don't count that as argument. I would need to know why these projects
> chose Mercurial over Bazaar and if these reasons are still valid. On
> http://www.dribin.org/dave/blog/archives/2007/12/28/dvcs/ you can find:
>
> """
>> Historically, the main complaint about Bazaar has been it’s
>> performance. In fact, the main reason why OpenSolaris dismissed
>> Bazaar was due to poor performance. But that eval was a year ago,
>> which is essentially an eternity. Since then, Bazaar has hit 1.0 and
>> those performance criticisms have supposedly been addressed.
> """
>
> so I read performance was the main reason, and that one is not that
> valid anymore. ..
> http://opensolaris.org/os/community/tools/scm/bzr-eval/ suggests the same.
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.
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.
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.
Jim
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
« Return to Thread: should we use bazaar?
| Free embeddable forum powered by Nabble | Forum Help |
