What do folks here see as the relative strengths and weaknesses of Git, Mercurial, and Bazaar?
In considering each of them with one another and against version control systems like SVN and Perforce, what issues should be considered?
In planning a migration from SVN to one of these distributed version control systems, what factors would you consider?
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.
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).
Mercurial and Bazaar resemble themselves very much on the surface. They both provide basic distributed version control, as in offline commit and merging multiple branches, are both written in python and are both slower than git. There are many differences once you delve into the code, but, for your routine day-to-day tasks, they are effectively the same, although Mercurial seems to have a bit more momentum.
Git, well, is not for the uninitiated. It is much faster than both Mercurial and Bazaar, and was written to manage the Linux kernel. It is the fastest of the three and it is also the most powerful of the three, by quite a margin. Git's log and commit manipulation tools are unmatched. However, it is also the most complicated and the most dangerous to use. It is very easy to lose a commit or ruin a repository, especially if you do not understand the inner workings of git.
Take a look at the comparison made recently by the Python developers: http://wiki.python.org/moin/DvcsComparison. They chose Mercurial based on three important reasons:
The choice to go with Mercurial was made for three important reasons:
- According to a small survey, Python developers are more interested in using Mercurial than in Bazaar or Git.
- Mercurial is written in Python, which is congruent with the python-dev tendency to 'eat their own dogfood'.
- Mercurial is significantly faster than bzr (it's slower than git, though by a much smaller difference).
- Mercurial is easier to learn for SVN users than Bazaar.
A very important missing thing in bazaar is cp. You cannot have multiple files sharing the same history, as you have in SVN, see for example here and here. If you don't plan to use cp, bzr is a great (and very easy to use) replacement for svn.
I was using Bazaar for a while which I liked a lot but it was only smaller projects and even then it was pretty slow. So easy to learn, but not super fast. It is very x-platform though.
I currently use Git which I like a lot since version 1.6 made it much more similar to other VCS in terms of the commands to use.
I think the main differences for my experience in using DVCS is this:
In summary Bzr was great when I was cutting my teeth on DVCS but I'm now very happy with Git and Github.
This is a big question that depends a lot on context that would take you a lot of time to type into one of these little text boxes. Also, all three of these appear substantially similar when used for the usual stuff most programmers do, so even understanding the differences requires some fairly esoteric knowledge.
You will probably get much better answers if you can break your analysis of these tools down to the point at which you have more specific questions.
Bazaar is IMHO easier to learn than git. Git has a nice support in github.com.
I think you should try to use both and decide which suits you most.
What do folks here see as the relative strengths and weaknesses of Git, Mercurial, and Bazaar?
This is a very open question, bordering on flamebait.
Git is fastest, but all three are fast enough. Bazaar is the most flexible (it has transparent read-write support for SVN repositories) and cares a lot about the user experience. Mercurial is somewhere in the middle.
All three systems have lots of fanboys. I am personally a Bazaar fanboy.
In considering each of them with one another and against version control systems like SVN and Perforce, what issues should be considered?
The former are distributed systems. The latter are centralized systems. In addition, Perforce is proprietary while all the others are free as in speech.
Centralized versus decentralized is a much more momentous choice than any of the systems you mentioned within its category.
In planning a migration from SVN to one of these distributed version control systems, what factors would you consider?
First, lack of a good substitute for TortoiseSVN. Although Bazaar is working on their own Tortoise variant, but it's not there yet, as of September 2008.
Then, training the key people about how using a decentralized system is going to affect their work.
Finally, integration with the rest of the system, such as issue trackers, the nightly build system, the automated test system, etc.
ddaa.myopenid.com mentioned it in passing, but I think it's worth mentioning again: Bazaar can read and write to remote SVN repositories. That means you could use Bazaar locally as a proof-of-concept while the rest of the team is still using Subversion.
EDIT: Pretty much all the tool now have some way of interacting with SVN, but I now have personal experience that git svn works extremely well. I've been using it for months, with minimal hiccups.
Your major issue is going to be that these are Distributed SCMs, and as such require a bit of a change to the user's mindset. Once people get used to the idea the technical details and usage patterns will fall into place, but don't underestimate that initial hurdle, especially in a corporate setting. Remember, all problems are people problems.
There is good video by Linus Torvalds on git. He is creator of Git so this is what he promotes but in the video he explain what distributed SCMs are and why they are better then centralized ones. There is a good deal of comparing git (mercurial is considered to be OK) and cvs/svn/perforce. There are also questions from the audience regarding migration to distributed SCM.
I found this material enlightening and I am sold to distributed SCM. But despite Linus' efforts my choice is mercurial. The reason is bitbucket.org, I found it better (more generous) then github.
I need to say here a word of warning: Linus has quite aggressive style, I think he wants to be funny but I didn't laugh. Apart from that the video is great if you are new to distributed SCMs and think about move from SVN.
Distributed version control systems (DVCSs) solve different problems than Centralized VCSs. Comparing them is like comparing hammers and screwdrivers.
Centralized VCS systems are designed with the intent that there is One True Source that is Blessed, and therefore Good. All developers work (checkout) from that source, and then add (commit) their changes, which then become similarly Blessed. The only real difference between CVS, Subversion, ClearCase, Perforce, VisualSourceSafe and all the other CVCSes is in the workflow, performance, and integration that each product offers.
Distributed VCS systems are designed with the intent that one repository is as good as any other, and that merges from one repository to another are just another form of communication. Any semantic value as to which repository should be trusted is imposed from the outside by process, not by the software itself.
The real choice between using one type or the other is organizational -- if your project or organization wants centralized control, then a DVCS is a non-starter. If your developers are expected to work all over the country/world, without secure broadband connections to a central repository, then DVCS is probably your salvation. If you need both, you're fsck'd.
© 2022 - 2024 — McMap. All rights reserved.
