Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Ian Clatworthy <ian.clatworthy <at> canonical.com>
Subject: Info Q article on DVCS - a request and some feedback
Newsgroups: gmane.comp.version-control.bazaar-ng.general
Date: Friday 9th May 2008 10:26:06 UTC (over 9 years ago)
Hi Sebastien,

Well done on your InfoQ article re DVCS tools. It looks quite well
researched and well written. If you're interested, I'd like to provide
some more information on Bazaar. Perhaps it's worth updating the article
to reflect this?

First though, can I make a request? Can you make the exact git, hg and
bzr repos you used available? I'd like to run some more performance
tests using them. More on this at the end of this email.

OK, some feedback on the comparison table you presented:

1. bzr EOL conversion support is under active development by me.
   My hope is that Bazaar will support this in 1.6. (We're
   packaging the 1.5rc tomorrow so it will miss that.)

2. Partial checkout support is also planned. See
   http://bazaar-vcs.org/FilteredViews.

3. Per file commit. You can record per file commit messages,
   in addition to the overall commit message, using bzr-gtk.

4. Rebase/Queues. These are both really well supported by Bazaar
   plugins. See http://bazaar-vcs.org/Rebase,
   http://blogs.gnome.org/jamesh/2008/04/01/bzr-loom/
and
   http://bazaar-vcs.org/Documentation/LoomAsSmarterQuilt.

5. Web access. Bazaar is every bit as good as git and hg here. In fact,
   it's far easier to set up static serving over http using Bazaar than
   Git. Static http serving is also *much* faster in bzr than in hg.
   I suspect bzr is quicker than Git here as well (given our smaller
   repo size for many projects) though I'm yet to measure that.

6. I agree that gitweb and hgweb are currently ahead of bzr's options.
   Loggerhead - you didn't include that in your table - is pretty good
   though if a bit annoying to set up.

7. Under cool extensions, you should mention shelf - part of BzrTools.
   (I believe it's directly comparable with git-stash.) bzr-dbus and
   bzr-ahavi are also really cool for hackers when sprinting.

8. TortoiseBzr is a Windows tool, not a Linux one. It is currently under
   active development. See
http://doc.bazaar-vcs.org/bzr.dev/developers/tortoise-strategy.html.

9. Before Tortoise matures, WildcatBZR is probably the best option
   right now for an integrated GUI. It's been tested on OS X and XP
   and ought to run on Linux as well. See
   http://sorn.net/projects/wildcat-bzr/about.php.

10. Submodules are supported in Bazaar by a related tools called
    ConfigManager. See http://bazaar-vcs.org/3rdPartyTools.
This
    is a common need and we don't cover it yet in the User Guide.
    I need to address that soon.

11. In the Migration section (which probably should be called
    Interoperability instead?), I'm curious as to why you marked
    Bazaar down versus the competition. We believe bzr-svn is actually
    the leading option here. See
    http://permalink.gmane.org/gmane.comp.gnome.desktop/36309.

Performance. Thanks for your benchmarking. I'm particularly curious
about the clone figures though: most of my benchmarking puts Bazaar
clone ahead of git clone. Did you use a shared repository? I'd be happy
to repeat your tests (and expand them) using a shared repo if you make
the hg and git repos you used available. I've also expanded
http://bazaar-vcs.org/Benchmarks
to include a place to reference
independent benchmarks of Bzr vs Git vs Hg performance. Please feel free
to add your article there.

So what section. I'd be very happy to update the BzrVsGit and BzrVsHg
pages on our Wiki if you'd point out which bits are incorrect. These
pages aren't there to "bash" the competition: they are there to point
out our strengths, and to provide links we can point (the never ending
stream of) people to whom ask us why they ought to use Bazaar. As well
as being the right thing to do ethically, it's absolutely in our
interest to ensure those pages are defensible. Please help us by
pointing out explicitly why you think they are "not-all-true".

Ian C.
 
CD: 3ms