Dave Abrahams <dave <at> boostpro.com> writes:
More attention from the community, more support, more tools work with it, more money behind it, more people will be familiar with it in the long run, etc., etc.
Example: compare the number of commercial tools for working with Git, compared to those available for working with Mercurial. On OS X along I can use: SourceTree, Tower, GitHub, GitBox, GitDiary, QuickHub, Octopus, and that's only the commercial tools!
By contrast, if I search for "mercurial" in the AppStore, I can only use SourceTree (which works with both).
Well, I am the author of MacHg a very fully featured multithreaded osx client for mercurial. There was murky and a few other clients around for OSX. But for now the scene seems to have settled into MacHg and SourceTree. I would also point out that I think the kiln team will soon have a nice port of TortiseHg to OSX. A partial listing of general tools is here: http://mercurial.selenic.com/wiki/OtherTools (Note I have not put MacHg on the AppStore since it is a bit of a pain trying to sand box the thing. I think Neil (the author of SourceTree) complained about the fact that he could not include compiled python file etc, in the app store version. Also a good GUI should have some command line drivers. Eg from the command line you should be able to enter "machg somerepo" and have it open in MacHg or something similar. (This has been on my to-do list for quite some time.) And such tools contravene the AppStore guidelines. Eg BBedit had to remove such tools from their application in order to get it onto the AppStore. Eg see http://www.barebones.com/store/macappstore.html and the section about the limitations of the AppStore version.)) I would think most developers would not be strictly limited to the AppStore version and a simple google of "OSX mercurial" will turn up MacHg... As to the whole discussion of Mercurial vs Git. I really have to say that both products are quite similar now in what they can do. However, the learning curve for me for git is just not good. Eg just for some simple comparisons do a: [salt:~] ⌘ hg help pull | wc 40 264 1753 [salt:~] ⌘ git help pull | wc 638 3624 29834 These are basically the same commands. Yet, the size of the help entry for pull for mercurial is 6% of the size of the git help entry. That says a lot about the understandability of one system to the other. (cf the size difference for other commands like pull, log, status, etc.) Git has **soo** many bells and whistles. Every so often as a real DVCS ninja git has something that mercurial doesn't have in my experience. Eg there is a feature in git when you are doing a total conversion of a repository you can run a filter over all of the files as you go. (eg imagine you want to convert all of say windows newlines to unix newlines in every version stored in history, or some other repetitive thing like this.) Up until a little while ago Mercurial didn't have that feature. So on the extreme cases there are definitely bits to git where git has more options. However these extra command switches in git are definitely a very sharp double edged sword in that for the average user the number of git options is just insanely huge. Thus I think the mercurial philosophy of trying to keep things clean, organized, and coherent is much better for at least 90% of users if not more like 98% of users. I am sure that each of you and each of your colleagues are gurus in a number of things, but do you want to require that they are gurus in DVCS systems? Even in Mercurial a lot of the users I encounter are sometimes woefully clued in to what is going on, and Mercurial is more streamlined, and cleanly organized than git (in my humble personal experience.) And it isn't all a bed of roses in Mercurial either. Eg there are things one should really watch out for, for example in using sub-repositories (these parallel sub-modules in git) one should use a thin super-repo layer. We got bitten by this at our work and it has caused problems. See eg http://mercurial.selenic.com/wiki/Subrepository#Recommendations Other points to consider: Those people who think you can't edit history in Mercurial or have many "branches" within a repo, their information is years out of date... I edit history and rebase, etc all of the time. It is part of my standard work flows. The arguments about popularity might have some weight but I think Mercurial and Git are definitely both large enough and will stick around. Besides converting one repo to the other in case one disappears is not that difficult. There are tools which interoperate between both formats (se hg-git.) Also, being a GUI writer I would say the number of differences once you are using a GUI is even smaller in day to day usage once you know what is going on. One, difference is with git you have to be careful to name *everything* or you get "detached heads". In mercurial you don't have to worry about this at all. You can happily update to any revision and start working right there without having to remember to name it / think up a name for it. (However, there are certain advantages to naming everything since then you can track revisions across all sorts of history edits, where-as in Mercurial you have to do some of this tracking manually...) (As a GUI writer I have thought about making the changes to MacHg to be able to release MacGit, but ever time I start playing with git it just... I don't know... I can go into details but the details would likely not be relevant here...) In any case, I use boost in my projects and think it's fantastic! Whether you all end up choosing git or hg a DVCS IMHO is much better than a centralized VCS. (However, I haven't used svn extensively since the company I worked for has skipped directly from cvs to mercurial & git.) Also whether you choose hg or git you might want to have an official mirror in the other system... So users can just use the system they want to. Best of luck, Jason
participants (1)
-
Jason Harris