| |||||||||||||
Mercurial: an alternative to gitMercurial: an alternative to gitPosted Sep 15, 2005 13:13 UTC (Thu) by arcticwolf (guest, #8341)Parent article: Mercurial: an alternative to git
Interesting article, but I wish there'd been more comparison of git's and mercurial's actual features, not to mention a list of "cons" (which I have no doubt exist, too).
Right now, it sounds like mercurial is the best thing since sliced bread and everyone should convert to it immediately since it's superior to every other SCM out there; a more critical look would've been nice.
(Log in to post comments)
Mercurial: an alternative to git Posted Sep 15, 2005 14:39 UTC (Thu) by bos (guest, #6154) [Link] Caveat lector: I work on Mercurial a lot.
The sets of features are quite similar, particularly with core features. There are a few differences in things you can do with non-core commands, but nothing terribly significant.
The bigger difference between the two is in how the user interfaces "feel". This doesn't affect the functionality of either system, but I think that Mercurial has a more complete, consistent command line UI than git, and certainly one that's more familiar to CVS or SVN users.
Mercurial: an alternative to git Posted Sep 15, 2005 19:29 UTC (Thu) by rickmoen (subscriber, #6943) [Link] IMVAO, git's pack format and repack command are more than a bit kludgey and inelegant. Why should SCM users have to fiddle with such things? Mecurial sidesteps that mess entirely, by being built on deltas in the first place. Also, because Mercurial runs anywhere Python does, it has an inherent portability advantage over git/Cogito (Bourne shell and other Unixisms). That design limitation of git/Cogito doesn't bother me, but does limit deployment for others. Mercurial's progress in a very short time has been impressive: I'm keeping an eye on that and Bazaar 2/bzr (ne Bazaar-NG) as the best hopes. Others will very defensibly favour darcs, Codeville, Monotone, ArX. Rick Moen
... and the others? Posted Sep 16, 2005 8:11 UTC (Fri) by ncm (subscriber, #165) [Link] Several other projects with similar goals started well before the Bitkeeper fiasco came to a head, among them Arch/Bazaar, Monotone, Codeville, and Darcs, and ought to be a lot more mature than Git or Mercurial. Monotone, in particular, got a lot of attention about the time Git and Hg started, mainly for being taken seriously but found to be too slow. I know it has since been sped up enormously, and got lots of important user-interface features.
Have the earlier projects turned out to be prototypes for a more modern, radically simpler generation of production-ready systems? Or should we consider them on even footing with Hg, expecting the latter to complexify to match as it matures and gains important features? Or, are Git and Hg interesting mainly to kernel maintainers, while those of us with more typical needs will be better off with one of the more mature products?
It seems clear there are too many of these projects, and some will stall as everyone's respective itches get scratched. How many should we expect will still be vigorous in, say, three years' time, after adopting the important features of the others and winning over current CVS holdouts? I.e., how many ecological niches are there, really?
... and the others? Posted Sep 17, 2005 1:35 UTC (Sat) by rickmoen (subscriber, #6943) [Link] Nathan: Monotone: On the plus side, it's in a halfway reasonable language (C++, with "hooks" in Lua), and the gripe about performance seems unfair, as that was a temporary glitch that is long gone. On the minus side, when last I heard, it was still considered a bit beta-ish; requires a dedicated server component rather than being reachable over commodity http; and identifies changesets by their SHA1 checksums, which is a bit cluttered. GNU Arch ("tla"): Seemingly moribund, given first the departure or many developers to Bazaar 1.x ("baz"), and then more recently the resignation of Tom Lord. Tom prototyped his own GNU Arch 2.0 redesign, dubbed "revc" (to fix some of tla's more hideous misfeatures, IMVAO), but nobody's yet adopted it in the wake of Tom's departure. Maybe someone from the tla-user community will comment, but all I'm seeing is unhappiness and a slow exodus to elsewhere (especially baz/bzr and ArX), among this camp. Bazaar 1.x ("baz"): Recently back-burnered by Canonical in favour of Martin Pool's more-ambitious Bazaar 2 "bzr" (formerly Bazaar-NG) project as the intended successor. ("baz" has been declared to be in "maintenance mode", as opposed to being actively developed.) Codeville: Close to mature, but still has a to-do list. E.g., last I heard, non-ASCII files and some file metadata still weren't handled. Last I heard, didn't have much docs. Intriguing, advanced merge algorithm that should be studied more widely. Uses SRP as network transport; I'm going to have to read Bram and Ross's reasons before I decide what I think about that. (Cannot be accessed over commodity http, anyway.) darcs: Drawbacks: How many people can hack Haskell? Stores repository metadata within the checked-out working area. Nagging performance problems (sometimes). Advantages: Good all-around system. Tracks inter-patch dependencies well. Patches from others can retain their separate identity even after integration (are not collapsed/rolled up). Implementation of "cherry-picking" is exemplary. It's difficult to judge how broad the appeal is, of most of these things: However, I do know that Hg is in commercial, production usage at one non-kernel software house of my acquaintance (Xenworks). Anyhow, I try to keep up, as best I can. (If I'm judged misinformed and in desperate need of reeducation, I wouldn't be the least bit surprised. It might even be true.) Rick Moen
... and the others? Posted Sep 17, 2005 3:30 UTC (Sat) by kevinbsmith (guest, #4778) [Link] I think Rick Moen's post is a pretty fair summary of many of the other systems.
In my mind, the big distinction between the first generation and the second is simplicity. Simplicity of UI, and simplicity of the underlying model. Gnu arch (tla) was extremely large and complex. ArX and Baz forked largely to simplify it, but they are both still somewhat on the heavy side. Monotone and codeville have simpler UI's, but they require a server daemon which makes them feel non-minimal.
Git (and cogito) popularized the "lightweight" tool, helping increase interest in mercurial and bzr. Of course, darcs had a great (simple) UI long before it became cool to have one, and it remains the most mature of the lightweight options.
There is a revctrl list/wiki/irc for mostly-technical cross-system SCM discussions:
Personally, I'm happy to see all these projects advancing so rapidly. None of them quite have all the features I need yet, but I'm optimistic that at least one will within the next few months. I doubt we will see a single dominant distributed SCM tool emerge for at least a year or two, due to different projects having distinctly different requirements.
... and the others? Posted Sep 22, 2005 18:35 UTC (Thu) by bos (guest, #6154) [Link] Kevin, if you need features, just ask :-)
Missing features Posted Sep 23, 2005 12:54 UTC (Fri) by kevinbsmith (guest, #4778) [Link] Actually, I have asked. I have been on the ArX, mercurial, and bazaar-ng lists for quite a while now. I was on the git/cogito list until it became clear to me that nobody was working on a user-friendly, command-line front end (such as cogito) that would be cross-platform.
One feature request for all systems is to have an eclipse plugin. As far as I know, only darcs has one, and it is still very preliminary.
I have requested that ArX get a simpler UI. The maintainer agrees that's a good idea, but it will take some serious reworking to achieve.
I have requested that mercurial support cheap branching on systems that don't have hardlinks. My three posts to the mercurial list asking about the feasibility of adding this feature have all, surprisingly, gone unanswered.
The bazaar2 folks have explained their plans to solve that cheap branching problem by adding "centralized storage". I believe they even have some prototypes working, but it looks like it's still a couple months away from being an official part of the product.
There is an experimental monotone add-on that supposedly allows you to serve a readonly repo on a cheap (http-only) web server. If that becomes mature, it might make monotone workable for me. Something similar could presumably be written for codeville.
Missing features Posted Sep 23, 2005 16:28 UTC (Fri) by bos (guest, #6154) [Link] We'd all love to have Eclipse plugins, I'm sure, but the unfortunate fact is that the current user communities of the various tools have not contributed any. Whether this is due to lack of interest, time, or experience I cannot say.
If you wanted to write one yourself, I am sure it would be very welcome.
... and the others? Posted Sep 22, 2005 18:51 UTC (Thu) by Omnifarious (guest, #19508) [Link] I've looked briefly at these other systems, and all of them seemed too complex to be worth using. The only one I don't have any experience with is Monotone. In contrast, Mercurial was simple to set up and easy to use. I'm a Subversion user from the early days of Subversion, and it was much easier than Subversion to set up for the first time. Then, as I started playing more with it, it became quite obvious and clear how I could solve the "I have a work machine, a home machine, and a laptop, and I work on all of them and don't always remember to sync." problem. After that, I was hooked. None of the other systems I've used have even come close to the external elegance and simplicity of Mercurial. And as I look deeper into its design, it's clear that it's external coherency is a reflection of a set of well-thought-out design principles. So, I guess I'm a convert and can be put into the "It's the greatest thing since sliced bread!" category. I can understand caution though. It's quite possible there is some fundamental design problem that I'll encounter after I understand it enough. I felt similarly about Java in the mid 90s, and it took me a few years to realize what was wrong with it.
|
|||||||||||||