Strengths of Mercurial: The view of People from the mercurial Mailing-List
This is an as of yet unsorted list of opinions from mercurial users. It still contains double entries and stuff. They are extracted from a thread in the mercurial list begun with the question: [http://article.gmane.org/gmane.comp.version-control.mercurial.general/11364 'What are the strengths of Mercurial for you?'] Pelase feel free to clean, sort and edit it.
A reworked result of this thread can be found in InformationFlow.
Very simple. I wanted a VCS that allows me to work over HTTP, such that I can control access to it myself using .htaccess. The only systems that claim to be able to do that as a non-root user, are bzr and hg. I started fiddling around with bzr initially, because of the big name behind it, but found out that bzr still has (or at least had at the time) many issues in this area. It took days to find this out and it still didn't work.
Then I tried hg and after a few hours I had exactly what I wanted using the very neat hgwebdir.cgi script. So for me the strength is: _it does what it promises_. (even though after using hg for some time, I think the documentation really needs attention; I find it extremely hard to find things in all the info that is scattered around the wiki)
J.S. van Bethlehem
1. the graph in tortoisehg
2. mq (though it could be better, it already is leaps and bounds better than manually dealing with patches in svn)
3. hg help XXX always seems to have the information I need
4. bugzilla integration (though I wrote my own extension for it because the one there didn't yet support bz 3+); the original bugzilla extension is what sold me on mercurial in the first place simply as an example for me to use to make my own update to it
1. Fast, without limiting how I work (as opposed to Bazaar, for example, which requires me to put all my branches under a shared repository if I'm to get fast cloning).
2. Solid Windows support (from the command line - I understand TortoiseHg is good, but I don't use it myself).
3. Just works the way I expect - very few surprises.
4. Core is extremely stable but there's lots of interesting developments as extensions.
FWIW, (1) is the key one that makes me prefer Mercurial over Bazaar (combined with 3 and 4 as far as repo formats are concerned), and (2) is the key one that makes me prefer Mercurial over Git.
4. Over "classic" VC systems: It's so easy to start a project -- hg init, and you're good to go.
Absolutely. I didn't mention it in my list simply because (1) it never occurred to me :-) and (2) it's not unique to Mercurial, but rather is a feature of most (all?) DVCSs.
But very definitely, the biggest benefit of using a DVCS is how easy it is to start using it, even on the most trivial projects.
- Paul Moore
While powerful enough for the most demanding project and workflow needs, it is also simple enough to be used by the lone and less-experienced developer.
Another real benefit of this software is that lone developers can begin to learn some of the skills required for team development.
My personal experience. I was a happy SVN user and then, incidentally, found a post about the BitKeeper controversy so. Not remembering exactly how, I ended up installing and trying Mercurial.
It took me one evening to get comfortable with it. About a month to better understand its distributed nature.
Then I tried git, but after two days of being stuck with the index concept I gave it out. An average control of git required me to try three more cycles of trial and abandonment (spread in about six months). But I must confess that understanding Mercurial has helped me to understand git, and vice versa. Now I have a better idea about where Mercurial is stronger and weaker.
Apart from that, I've managed to set up the hgweb in a very restricted hosting service. I'm not very convinced about achieving the same with git.
- Straightforward (simplicity is also a feature nowadays).
- The lack of repository maintenance (compared to git).
- The template engine.
Some of the important advantages of Mercurial for me are (in order of decreasing importance):
I understood how to install Mercurial and how to use it in a few minutes. Now, after having used it for a long time, I feel confident that I can explain the basic concepts to other people in a few minutes too.
I cannot stress enough how important this is. A VCS is often used by two sets of people: release managers and developers. The first set of people tends to love and embrace byzantine monsters of infinite complexity, because they provide all the bells and whistles they need to accurately track the `when', `who', `how' and `why' of a change. The second set of people tends to prefer simpler systems that ``get out of the way'' and let them ``do their work'' without a lot of trouble.
Mercurial strikes a marvelous balance between these two ends. It can be configured to support either simple environments or very complicated streams of changes interacting in custom ways, and it does all that without becoming a humongous monster of complexity.
- Lack of surprises:
The command line UI is _very_ predictable and easy to learn. The names of many basic commands have the same meaning as those of CVS and Subversion.
- This way people coming from those other VC systems can really expect "hg add" to add a file to the repository and not do something surprising or even wrong.
- Easy command names and predictably, very uniform options for those commands means that it is often quite easy to `guess' what a command does even if one has not used it until now (the --git, --rev and --template options are good examples of this sort of ease & uniformity).
- It is easy to use & write extensions:
The existing extensions cover a lot of the functionality a new user might require. Writing new ones is easy and the Wiki has nice documentation describing how to do it. The code of the existing extensions is a nice read too; seeing how other people have hooked into Hg and extended its core functionality, using a wonderful language like Python helps a lot when one is trying to create new extensions from scratch or to extend one of the current extensions.
MQ allows you to do some amazing stuff and the fact that you can share it as a repo is really helpful. As I mostly develop websites, I use MQ to keep patches on config changes seperate for each environment
The dev's of Hg are generally friendly and approachable - Git devs are often Kernel devs, so be ready for some nastiness
Windows support for HG is good
And for some reason Git takes 8 seconds to do a commit on my machine. There's something wrong with my setup... but I have just never bothered to figure out why cause Hg just worked
The code base for Hg is pretty small and yet its pretty feature complete. Stability in the underlying repo structure and it tends to be pretty backward compatible
Today: simplicity, being distributed, extensibility, speed, familiarity, bash completion, understandable and reasonably small code base (well, still need to get a full picture of changegroupsubset).
When I started:
1. Does not get in the way
What initially sold my was the ability to work without IDE integration. I used Svn within Eclipse, and it just told me after one rename refactoring where I chose a bad name that, no, you cannot rename again before you commit. Duh! A VCS should *not* dictate how I refactor.
So I looked at Hg, and it has `hg addremove --similarity`. (Since then, I have updated this a little so I have `hg addrem; hg guessrenames`, where I can repeat the guessrenames with different similarity settings until I like them.) Anyhow, it allows me to work without any VCS IDE integration at all, removing one pain point. Bzr didn't have this (still doesn't, I think) and it's what clinched the deal for me.
And `hg add` is much more directly useful than `svn add`, too.
Though something like shelve should really be built-in, I think. This is where today I get most instances of thinking that it's getting in my way.
2. Has good Windows support
I started on Windows, but seeing how good bash-completion for hg is actually won me over to Linux. ;)
3. Has only one .hg folder, not the .svn nightmare
Even today I see experienced SVN folks check in stuff they copied in the file system from one branch to another to the original branch again because the .svn folders got copied too.
4. Is distributed and works offline
I work at home, on the train, in cafes, in different machines, etc. And the team on the project gradually grew from just me to a few people here and abroad. This was a totally seamless experience, even while we had no central server and were simply exchanging bundles via FTP or email. And everybody got up to speed quickly.
Easy to understand at a practical level. I can easily figure out how to get it to do what I want, particularly when it comes to pushing and pulling from multiple remote repositories.
I really like Git's underlying model (a DAG of blobs is rather elegant), but I came back to Mercurial because I find it much easier to make it work for my day-to-day usage (especially working with a setup where I have a forest, and my laptop copy pushes and pulls between the file server, live web, and test web, and live and test web going between each other and the file server -- I got totally confused trying to do that with Git, but it was trivial to understand what Mercurial was doing).
The reasons we switched to mercurial, about two years ago, where:
- Easy to learn (we liked the hg book).
- Works on many platforms.
- Stable (no big changes in command syntax, repository format, etc.)
- "hg serve", the easiest repository browser available!
I think that if we where switching away from CVS today, the decision on which DVCS would be a lot more difficult, because a lot of that points are also covered with git and bzr.
The main advantage today, and something that I think you should advocate is the included web server, as it replaces a lot of functionality of GUI tools in a truly multiplatform way.
- Distributed - Teams working on different continents. Utterly trivial to set up local clone redistribution points and backups.
- hg serve - instant salesman for showing core concepts, what history looks like, etc.
- zip/tar/etc. archives - Ability to give internal customers a URL and a button to click. No need to install any version control clients to just get a snapshot of our system and use it.
- TortoiseHG - I was the only one on my team who didn't use WinCVS; a command line only version control solution had no chance.
- Trivial install on Windows - TortoiseHG again. I can use the command line and only delve into the GUI when I need to help other team members, all from one install.
- Append only repo model - Even junior members of the team can play, and if they accidentally commit to the wrong repo, well, repo-life is append only, no worries, we just back up a few changesets, branch around them, and it doesn't take any significant time to recover.
- Cheap clones.
- Learning curve. Despite the immaturity of TortoiseHG and the rather diffuse and scattered Mercurial wiki, there isn't much to learn to be effective; within a particular (policy determined) workflow productivity doesn't take long to achieve.
1) Its mostly python and therefore for me anyways, easy to understand
2) Its very fast, git is faster but not noticably so for most things and the few things that are a little slower I don't do often ( cloning, checking the entire log )
3) branching is cheap and easy, I move my working repository to the version I want to branch from and continue to work there. I've branched and it was near instant.
4) easy install, if you can even call it an install at all since it Just Works on every platform that I've used with a C compiler and python (all the ones I care about have this). Its fast on all of them as well.
5) it has a tortoise so I can actually show my boss its highly productive even in windows (even though I think tortoisehg could use some usability studies and workflow improvements).
6) it took my less than an hour to understand it. I still don't know what half the git commands do, I know pretty much all of the hg ones I care about, definitely all of the hg ones that come with it.
7) color diff
8) color status
9) merging uses my merge tool
What I like:
a) the speed
Oh, I haven't mentioned the speed, but that's because it's became natural for me. :-)
a) the speed
b) the ease of use - the commands usually do what I assume them to do :).
c) the ease of deployment
d) available features like sign, mq, bookmarks, serve
e) helpfulness and attitude on this list. Thanks a lot everyone :).
(A) Philosophy / Attitude (at all levels: project, design, community, etc.)
(B) Cleanliness / Consistency
(C) Stability / Reliability
(F) Focus (not trying to be everything to everybody)
(G) Windows support
John D. Mitchell
B) From a Bryan O'Sullivan's presentation (An introduction to Mercurial, Google, June 19th 2006):
User quote: “Mercurial's conceptual model is clean and simple enough to carry around in my head”
C) Very very nice community (users and developers)
D) tip is better than HEAD
1. The community is very nice. :) 2. I can serve via HTTP, which allowed me to set up a really easy repo-server for my student club 3. This is minor, but syntax highlighting on the repo browser is just neat. 4. Over "classic" VC systems: It's so easy to start a project -- hg init, and you're good to go.
On Monday 19 January 2009 15:20:49 Paul Fisher wrote:
4. Over "classic" VC systems: It's so easy to start a project -- hg init, and you're good to go.
Right. I always tell people this is the killer feature for me, I cannot stress that enough. How much code did I not check into CVS/SVN because I did never know a) where to put the repo b) what are the right commands [c) what should I choose as "vendor tag" etc.]
So, the strengths list for me is a) hg init b) simplicity - I know what a DAG is and I can very well imagine what happens in the repo through my actions c) it simply works - no real problems yet (except hgweb[dir] setup - error reporting could be improved there IMHO)
In the meantime, I have begun working with a lot of extensions (most lately crecord - nice!) etc., but it's good to start without.