What are the relative strengths and weaknesses of Git, Mercurial, and Bazaar? [closed] What are the relative strengths and weaknesses of Git, Mercurial, and Bazaar? [closed] git git

What are the relative strengths and weaknesses of Git, Mercurial, and Bazaar? [closed]


Git is very fast, scales very well, and is very transparent about its concepts. The down side of this is that it has a relatively steep learning curve. A Win32 port is available, but not quite a first-class citizen. Git exposes hashes as version numbers to users; this provides guarantees (in that a single hash always refers to the exact same content; an attacker cannot modify history without being detected), but can be cumbersome to the user. Git has a unique concept of tracking file contents, even as those contents move between files, and views files as first-level objects, but does not track directories. Another issue with git is that has many operations (such as rebase) which make it easy to modify history (in a sense -- the content referred to by a hash will never change, but references to that hash may be lost); some purists (myself included) don't like that very much.

Bazaar is reasonably fast (very fast for trees with shallow history, but presently scales poorly with history length), and is easy-to-learn to those familiar with the command-line interfaces of traditional SCMs (CVS, SVN, etc). Win32 is considered a first-class target by its development team. It has a pluggable architecture for different components, and replaces its storage format frequently; this allows them to introduce new features (such as better support for integration with revision control systems based on different concepts) and improve performance. The Bazaar team considers directory tracking and rename support first-class functionality. While globally unique revision-id identifiers are available for all revisions, tree-local revnos (standard revision numbers, more akin to those used by svn or other more conventional SCMs) are used in place of content hashes for identifying revisions. Bazaar has support for "lightweight checkouts", in which history is kept on a remote server instead of copied down to the local system and is automatically referred to over the network when needed; at present, this is unique among DSCMs.

Both have some form of SVN integration available; however, bzr-svn is considerably more capable than git-svn, largely due to backend format revisions introduced for that purpose. [Update, as of 2014: The third-party commercial product SubGit provides a bidirectional interface between SVN and Git which is comparable in fidelity to bzr-svn, and considerably more polished; I strongly recommend its use over that of git-svn when budget and licensing constraints permit].

I have not used Mercurial extensively, and so cannot comment on it in detail -- except to note that it, like Git, has content-hash addressing for revisions; also like Git, it does not treat directories as first-class objects (and cannot store an empty directory). It is, however, faster than any other DSCM except for Git, and has far better IDE integration (especially for Eclipse) than any of its competitors. Given its performance characteristics (which lag only slightly behind those of Git) and its superior cross-platform and IDE support, Mercurial may be compelling for teams with significant number of win32-centric or IDE-bound members.

One concern in migrating from SVN is that SVN's GUI frontends and IDE integration are more mature than those of any of the distributed SCMs. Also, if you currently make heavy use of precommit script automation with SVN (ie. requiring unit tests to pass before a commit can proceed), you'll probably want to use a tool similar to PQM for automating merge requests to your shared branches.

SVK is a DSCM which uses Subversion as its backing store, and has quite good integration with SVN-centric tools. However, it has dramatically worse performance and scalability characteristics than any other major DSCM (even Darcs), and should be avoided for projects which are liable to grow large in terms of either length of history or number of files.

[About the author: I use Git and Perforce for work, and Bazaar for my personal projects and as an embedded library; other parts of my employer's organization use Mercurial heavily. In a previous life I built a great deal of automation around SVN; before that I have experience with GNU Arch, BitKeeper, CVS and others. Git was quite off-putting at first -- it felt like GNU Arch inasmuch as being a concept-heavy environment, as opposed to toolkits built to conform to the user's choice of workflows -- but I've since come to be quite comfortable with it].


Steve Streeting of the Ogre 3D project just (9/28/2009) published a blog entry on this topic where he does a great and even handed comparison of Git, Mercurial and Bazaar.

In the end he finds strengths and weaknesses with all three and no clear winner. On the plus side, he gives a great table to help you decide which to go with.

alt text

Its a short read and I highly recommend it.



What do folks here see as the relative strengths and weaknesses of Git, Mercurial, and Bazaar?

In my opinion Git strength is its clean underlying design and very rich set of features. It also has I think the best support for multi-branch repositories and managing branch-heavy workflows. It is very fast and has small repository size.

It has some features which are useful but take some effort to be used to them. Those include visible intermediate staging ara (index) between working area and repository database, which allows for better merge resolution in more complicated cases, incremental comitting, and comitting with dirty tree; detecting renames and copies using similarity heuristic rather than tracking them using some kind of file-ids, which works well and which allow for blame (annotate) which can follow code movement across files and not only wholesale renames.

One of its disadvantages is that MS Windows support lags behind and is not full. Another perceived disadvantage is that it is not as well documented as for example Mercurial, and is less user friendly than competition, but it changes.

In my opinion Mercurial strength lies in its good performance and small repository size, in its good MS Windows support.

The main disadvanatge is in my opinion the fact that local branches (multiple branches in single repository) is still second-class citizen, and in strange and complicated way it implements tags. Also the way it deals with file renames was suboptimal (but this migth have changed). Mercurial doesn't support octopus merges (with more than two parents).

From what I have heard and read main Bazaar advantages are it easy support for centralized workflow (which is also disadvantage, with centralized concepts visible where it shouldn't), tracking renames of both files and directories.

Its main disadvantage are performance and repository size for large repositories with long nonlinear history (the performance improved at least for not too large repositories), the fact that default paradigm is one ranch per repository (you can set it up to share data, though), and centralized concepts (but that also from what I have heard changes).

Git is written in C, shell scripts and Perl, and is scriptable; Mercurial is written in C (core, for performance) and Python, and provides API for extensions; Bazaar is written in Python, and provides API for extensions.


In considering each of them with one another and against version control systems like SVN and Perforce, what issues should be considered?

Version control systems like Subversion (SVN), Perforce, or ClearCase are centralized version control systems. Git, Mercurial, Bazaar (and also Darcs, Monotone and BitKeeper) are distributed version control systems. Distributed version control systems allow for much wider range of workflows. They allow to use "publish when ready". They have better support for branching and merging, and for branch-heavy workflows. You don't need to trust people with commit access to be able to get contributions from them in an easy way.


In planning a migration from SVN to one of these distributed version control systems, what factors would you consider?

One of factors you might want to consider is the support for inetracting with SVN; Git has git-svn, Bazaar has bzr-svn, and Mercurial has hgsubversion extension.

Disclaimer: I am Git user and small time contributor, and watch (and participate on) git mailing list. I know Mercurial and Bazaar only from their documentation, various discussion on IRC and mailing lists, and blog posts and articles comparing various version control systems (some of which are listed on GitComparison page on Git Wiki).