15 ms·

I'm going to slowly move on from Mercurial

480 points by jordigh 11y ago

andrewla 11y ago
For context here, and for people like me who don't follow the development of Mercurial closely enough to realize, mpm is not just some random contributor to Mercurial, but is in fact Matt Mackall, the original author of Mercurial.
- jordigh 11y ago
  Lest we forget, Mercurial was offered as the other solution to the Bitkeeper problem, as mpm was a kernel hacker at the time. It got a usable UI at version 0.1, two weeks after the git announcement. Some git users relied on cogito for another year or so, as simple things like `git-commit` still had to be manually handcrafted out of `git-commit-tree`. I wasn't there to witness this, but I repeat it because it's actually kind of hard to dig up this history. I don't know of a single place that neatly chronicles the whole transition from bitkeeper -> git/mercurial.
  - JoshTriplett 11y ago
    > Lest we forget, Mercurial was offered as the other solution to the Bitkeeper problem, as mpm was a kernel hacker at the time. It got a usable UI at version 0.1, two weeks after the git announcement. I remember using Mercurial very early on in its lifetime, during my first internship at IBM, because Xen used it. Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Mercurial for that reason, because they had developers on Windows. Unfortunately, Mercurial took longer to develop some of its infrastructure, such as a repository structure optimized for performance, fast branches without making a separate working directory for each, and history editing capabilities. Today, as far as I know, Mercurial does have all of those things (some through plugins). > Some git users relied on cogito for another year or so, as simple things like `git-commit` still had to be manually handcrafted out of `git-commit-tree`. Many people (myself included) also used cogito as a crutch for a while longer, until really internalizing the value of the git index, because cogito defaulted to bypassing the index. I originally saw the index as an obstacle to the commit model I'd gotten used to from subversion. Today, I find it a critical part of git's culture of making small commits with one logical change each.
    - zeveb 11y ago
      > Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Mercurial for that reason, because they had developers on Windows. Ouch, yet another way in which running on Windows can lead to poor technical decisions. In my own case, I really preferred hg's command congruence to SVN; git's deceptive similarity took a long time to get over. > I originally saw the index as an obstacle to the commit model I'd gotten used to from subversion. Today, I find it a critical part of git's culture of making small commits with one logical change each. Same here, on both counts. I'd never go back, now, but it did take time to understand the benefits.
      - ngoldbaum 11y ago
        I do the same thing with mercurial's "hg commit -i" interactive interface. There's also a very nice curses interface for interactive hunk selection which is currently behind an experimental config flag but is shipped with the core application.
      - oblio 11y ago
        > Ouch, yet another way in which running on Windows can lead to poor technical decisions. That's quite dismissive of Windows...
      - pcwalton 11y ago
        > Ouch, yet another way in which running on Windows can lead to poor technical decisions. I didn't see any indication in the parent comment (or in general, really) that Windows support was the cause of Mercurial's difficulty in implementing those features.
        apetresc 11y ago
        He means that Mozilla devs running Windows led them to adopt Mercurial (which was, in his opinion, a "poor technical decision"). Not that Mercurial made poor technical decisions as a result of supporting Windows.
      - theandrewbailey 11y ago
  - schodge 11y ago
    There was no version control on the transition? :)
- billsix 11y ago
  Why is context needed when the first sentence is "Here it is 2016 and it's been almost 11 years since I started Mercurial." ?
  - mst 11y ago
    I thought the same thing. Then I thought about some of the subthreads on the Sun2 bootloader article. Then I recalibrated my cynicism.
  - klibertp 11y ago
    I don't know the GP intention, but for people who first look through comments here, before investing time in reading the piece this is a crucial information. I wouldn't read the article if not for this post.
- theandrewbailey 11y ago
  Thanks for the clarification. Initially, I was thinking mpm was another package manager.
BuckRogers 11y ago
Matt has done a great job and I wish hg had taken off more than it did, though it would be disingenuous to suggest it hasn't been successful. I used hg before moving to git and always preferred the clean, single language implementation vs the scripts and general hackish nature that git offered as an alternative. As a result, it was a nice perk for a long time that hg worked much better than git on Windows.
- masklinn 11y ago
  Also the revsets, while they're relatively recent in the grand scheme of things (hg 1.6 circa 2010) I so miss these when I have to use (or even read the man page of) the garbage fire that is `git log` (templates also help)
  - ngoldbaum 11y ago
    I've actually converted a git repo to hg just to use revsets.
  - roddds 11y ago
    What is it about these revsets that can't be achieved with a "git log --graph --decorate --all"?
    - jordigh 11y ago
      Those would be accomplished with hg templates, not revsets. Revsets are kind of like gitrevisions(7), but much more powerful. Docs: https://selenic.com/hg/help/revsets https://selenic.com/hg/help/revsets A complete example, which appears to have some popularity in Mozilla: http://jordi.inversethought.com/blog/customising-mercurial-like-a-pro/ http://jordi.inversethought.com/blog/customising-mercurial-l... edit: Sorry, the --decorate part would be with template, the --all is kind of like a revset, and the --graph part is well, --graph.
      - masklinn 11y ago
        > Those would be accomplished with hg templates Except for the --graph part which would be accomplished with --graph of course > Revsets are kind of like gitrevisions(7), but much more powerful. And easier to read and write too.
AndyMcConachie 11y ago
Thanks for all your contributions over these years.
- isxek 11y ago
  Thanks for starting Mercurial.
nailer 11y ago
hg could be 20% better than git. For the sake of the arugment, let's say it is. git's network effects mean hg needs to be 1000% better than git to replace it (much like git replaced svn, svn replaced cvs, and cvs replaced rcs).
- restalis 11y ago
  If people would judge a tool on its technical merits, that may be true. However, a lot of people that adopted git hardly needed/used git's improvements (in their one man projects).
- umanwizard 11y ago
  There are tons of companies using mercurial including some of the biggest ones. It's not really accurate to imply that Git won and Mercurial is dead.
  - soperj 11y ago
    Yes, For instance, Java.
    - umanwizard 11y ago
      Facebook is another example :)
  - amadvance 11y ago
    I consider the CPython switch from Mercurial to git the final declaration of victory. I still have to understand how CPython could miss the symbolic meaning of this decision.
    - mixmastamyk 11y ago
      It's probably more accurate to say they switched to github, but yes.
    - marcinkuzminski 11y ago
ChuckMcM 11y ago
This is a gutsy thing to do with a piece of software that has been part of your life for over a decade. Mad props to mpm. Up until Blekko I had pretty much been a perforce user (both at NetApp and at Google) and git was "that weird system you had to use to check in kernel changes". Blekko used Mercurial and I had no opinion as I had no experience. But over the years using hg at work and then starting up a github account to learn git, I saw the writing on the wall. Hg was the betamax of source code management systems. Clean, elegant, reliable, and not mainstream.
pjmlp 11y ago
I loved Mercurial, but just like with Wirth languages, I seem be on the wrong side of the mainstream flow. Thanks for Mercurial!
oscarcardoso 11y ago
If you ever see this, Thank you Matt. It helped me a lot to get away from subversion by working with hg at the same time.
indygreg2 11y ago
10+ years is a long time to steward a project. Most projects don't even live that long! Transitioning away after 10+ years is a sign of several positive things: * Creating a successful project that lasts 10+ years * Having the perseverance, patience, and willpower to guide that project for its lifetime * Creating a healthy community whom you are able to transition day-to-day responsibility of that project to Matt has accomplished something that most of us never will. I'm envious of what he has accomplished and that he is able to walk away from a healthy and successful project. Truly a remarkable accomplishment.
22klinda 11y ago
I've used Mercurial on Bitbucket in the past and loved it. Very thank you for your hard workd, Matt. Too bad that git is on everywhere now.
dhimes 11y ago
Thank you, Matt. hg is still my choice in source control. It's the only one I really use.
bedros 11y ago
I talked with an engineer from a fortune 500 tech company and they chose git over other vcs because they could have permission control; they have sensitive sub project who needs only a small set of engineers with permission to access it, but that subproject/module is part of a bigger project that everyone has access to. I personally prefer HG over git and use it for my own personal projects, hosted on my own redmine server. I tried bitbucket, and github; the latter have s superior interface to bitbucket. which I believe why people picked github over bitbucket
dochtman 11y ago
I was a Mercurial crew member for a few years (2008 to I don't know) and was very happy to be able to learn from Matt in his role as BDFL. His principled stance against layering violations and his policy to require really small commits still influence my coding every day. I hope he finds something new to give him satisfaction/joy!
- tonfa 11y ago
  +1, working with Matt was also extremely formative, I learned a lot of best practices during those years.
- ufo 11y ago
  What do you mean by "layering violations"?
stevelosh 11y ago
I've only contributed a few patches to Mercurial but meeting Matt and learning from him (mostly on the HG mailing lists) has taught me a lot. He's influenced how I think about and work with code at a really basic level. I wish him the best in whatever he decides to do.
krupan 11y ago
I'm really surprised by the "git won" mentality that manifests in any discussion of mercurial as of late. It makes no sense. We don't decare "winners" with other tools we use. Do we? Why are we all playing with new programming languages when C won? Or maybe C++ won? Or Java? Did emacs or vim win? Speaking of text, did ASCII win? Which code review tool won? How about continuous integration tools? or build tools? I mean, make won, right? None of us just pick the most widely used tool or programming language and say, "there can only be one" and then stop trying new things. Why are we doing this with version control?
- Avshalom 11y ago
  While emacs and vim are still duking it out people are CONSTANTLY defaulting to or arguing the case for this or that because "the right tool for the job" 90% of the time means "the tool the community supports for my problem"
- slapresta 11y ago
  Code collaboration tools have a strong network effect due to them being ultimately social tools, and we expect categories affected by the network effect to have winner/losers mechanics. Of course, they don't actually have to, but it's a common expectation and a common outcome. For equivalents to "code collaboration tools", instead of "programming languages", "text editors" and "build tools", try "social networks" (Facebook won, MySpace lost), "network protocols" (HTTP won, FTP and Gopher lost) or "spoken languages" (English won)
  - krupan 11y ago
    It seems to me that programming languages have far stronger network effects than any other example you or I are throwing out. If one project uses git and another mercurial and they want to work together, there are ways (hg-git, plain old patches). Try incorporating some java code in a ruby project, however. No possible way that is going to fly. Yet, we (at least the hacker news crowd) haven't declared any language as "winner". I really hope version control does not stagnate at git.
yeukhon 11y ago
I did a project on integrating Mercurial with Mongo before, and I have to say being a Python developer I didn't have too much difficulty in figuring the right API, although the documentation is not so great. The code itself uses a lot of abbreviations which you have to really be patient to get familiar. The Mercurial model [1] is a pleasant read for a couple train ride (read it a few times I encourage). Others have done amazing things with hg too, like making hg available in Javascript (now an abandon project). Mercurial is actually very easy to use. However, it didn't have the exact lightweight concept of git branch until they implemented bookmark a few years ago. I don't remember the limitation of bookmarks now it has been a few years since I used Mercurial... I too thank Matt and core developers working on Mercurial. One thing I feel Matt and developers need to address is hosting hg on PyPI infrastructure instead of redirecting to their own server. From time to time the server wouldn't deliver anything and it was frustrating to see our builds fail (of course some say you should have cached the build and not hitting Mercurial server every day). [1]: https://www.mercurial-scm.org/wiki/Presentations?action=AttachFile&do=get&target=ols-mercurial-paper.pdf https://www.mercurial-scm.org/wiki/Presentations?action=Atta...
- durin42 11y ago
  We've been uploading to PyPI as part of our release process for quite some time, and our own server is hosted on public infra now instead of on a privately managed machine. :)
acveilleux 11y ago
I believe that Mercurial's greatest flaw is that it is too damn easy to use. Since you don't have to wrap your head around it so damn much to use it, it seems weak, like if it was only slightly better than subversion. The truth is different and Mercurial is roughly as capable as git but it's easy to miss Mercurial's power where as Git rubs your face in it (less so these days but early on, it was a brain f* to my CVS trained brain.)
harry8 11y ago
You find yourself in a realm where hackers don't branch and use svn with no experience of distributed source control. hg is so much your friend here. They will actually probably get over the switch hump and use it. git that hump is much bigger and more arduous. Git is great, I like it. When you want to drag the team with you who aren't already sold, just go straight to hg every time. You're hacker, you can use either effectively and both are excellent tools.
anarazel 11y ago
I think hg was/is important, to provide competition to git. But I don't really understand all the people arguing that hg is so much easier to use, and so much cleaner. Sure, in the first few years that was true, and there's architecturally better choices (not a mess of scripts, embeddable as library). But from a day to day usage, hg seems worse to me. And that includes the documentation, something that really surprised me after I had to restart using hg a year or so back. The whole thing how hard it is to actually get rid of branches (no, I do not want to merge that branch. Yes, I don't want any central record anymore. No, I don't want to ssh into the remote box. Uh....), really bugged me. So does the need, slowly abating, to activate a lot of random plugins to get functionality that git had for years (pagers, incremental add, staging area, ...). But I very well, and I actually mean that, might just be mind warped by having used git so long and so continually that I just don't see the problems anymore and it just seems easier. I do remember some initial difficulties understanding it, but that was in the quite early days...
antonyme 11y ago
Mercurial has to be one of the best examples of incredibly high quality Software Engineering out there. It is very well-designed, reliable, fast, easy to use, well-documented and has a great community behind it. Matt deserves huge kudos for his enormous effort and commitment over the years. And like a true gentleman, he is leaving in style to ensure the transition is smooth.

480 points by jordigh 11y ago

For context here, and for people like me who don't follow the development of Mercurial closely enough to realize, mpm is not just some random contributor to Mercurial, but is in fact Matt Mackall, the original author of Mercurial.

jordigh 11y ago
Lest we forget, Mercurial was offered as the other solution to the Bitkeeper problem, as mpm was a kernel hacker at the time. It got a usable UI at version 0.1, two weeks after the git announcement. Some git users relied on cogito for another year or so, as simple things like `git-commit` still had to be manually handcrafted out of `git-commit-tree`. I wasn't there to witness this, but I repeat it because it's actually kind of hard to dig up this history. I don't know of a single place that neatly chronicles the whole transition from bitkeeper -> git/mercurial.
- JoshTriplett 11y ago
  > Lest we forget, Mercurial was offered as the other solution to the Bitkeeper problem, as mpm was a kernel hacker at the time. It got a usable UI at version 0.1, two weeks after the git announcement. I remember using Mercurial very early on in its lifetime, during my first internship at IBM, because Xen used it. Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Mercurial for that reason, because they had developers on Windows. Unfortunately, Mercurial took longer to develop some of its infrastructure, such as a repository structure optimized for performance, fast branches without making a separate working directory for each, and history editing capabilities. Today, as far as I know, Mercurial does have all of those things (some through plugins). > Some git users relied on cogito for another year or so, as simple things like `git-commit` still had to be manually handcrafted out of `git-commit-tree`. Many people (myself included) also used cogito as a crutch for a while longer, until really internalizing the value of the git index, because cogito defaulted to bypassing the index. I originally saw the index as an obstacle to the commit model I'd gotten used to from subversion. Today, I find it a critical part of git's culture of making small commits with one logical change each.
  - zeveb 11y ago
    > Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Mercurial for that reason, because they had developers on Windows. Ouch, yet another way in which running on Windows can lead to poor technical decisions. In my own case, I really preferred hg's command congruence to SVN; git's deceptive similarity took a long time to get over. > I originally saw the index as an obstacle to the commit model I'd gotten used to from subversion. Today, I find it a critical part of git's culture of making small commits with one logical change each. Same here, on both counts. I'd never go back, now, but it did take time to understand the benefits.
    - ngoldbaum 11y ago
      I do the same thing with mercurial's "hg commit -i" interactive interface. There's also a very nice curses interface for interactive hunk selection which is currently behind an experimental config flag but is shipped with the core application.
    - oblio 11y ago
      > Ouch, yet another way in which running on Windows can lead to poor technical decisions. That's quite dismissive of Windows...
    - pcwalton 11y ago
      > Ouch, yet another way in which running on Windows can lead to poor technical decisions. I didn't see any indication in the parent comment (or in general, really) that Windows support was the cause of Mercurial's difficulty in implementing those features.
      - apetresc 11y ago
        He means that Mozilla devs running Windows led them to adopt Mercurial (which was, in his opinion, a "poor technical decision"). Not that Mercurial made poor technical decisions as a result of supporting Windows.
    - theandrewbailey 11y ago
- schodge 11y ago
  There was no version control on the transition? :)
billsix 11y ago
Why is context needed when the first sentence is "Here it is 2016 and it's been almost 11 years since I started Mercurial." ?
- mst 11y ago
  I thought the same thing. Then I thought about some of the subthreads on the Sun2 bootloader article. Then I recalibrated my cynicism.
- klibertp 11y ago
  I don't know the GP intention, but for people who first look through comments here, before investing time in reading the piece this is a crucial information. I wouldn't read the article if not for this post.
theandrewbailey 11y ago
Thanks for the clarification. Initially, I was thinking mpm was another package manager.

BuckRogers 11y ago

Matt has done a great job and I wish hg had taken off more than it did, though it would be disingenuous to suggest it hasn't been successful. I used hg before moving to git and always preferred the clean, single language implementation vs the scripts and general hackish nature that git offered as an alternative. As a result, it was a nice perk for a long time that hg worked much better than git on Windows.

masklinn 11y ago
Also the revsets, while they're relatively recent in the grand scheme of things (hg 1.6 circa 2010) I so miss these when I have to use (or even read the man page of) the garbage fire that is `git log` (templates also help)
- ngoldbaum 11y ago
  I've actually converted a git repo to hg just to use revsets.
- roddds 11y ago
  What is it about these revsets that can't be achieved with a "git log --graph --decorate --all"?
  - jordigh 11y ago
    Those would be accomplished with hg templates, not revsets. Revsets are kind of like gitrevisions(7), but much more powerful. Docs: https://selenic.com/hg/help/revsets https://selenic.com/hg/help/revsets A complete example, which appears to have some popularity in Mozilla: http://jordi.inversethought.com/blog/customising-mercurial-like-a-pro/ http://jordi.inversethought.com/blog/customising-mercurial-l... edit: Sorry, the --decorate part would be with template, the --all is kind of like a revset, and the --graph part is well, --graph.
    - masklinn 11y ago
      > Those would be accomplished with hg templates Except for the --graph part which would be accomplished with --graph of course > Revsets are kind of like gitrevisions(7), but much more powerful. And easier to read and write too.

AndyMcConachie 11y ago

Thanks for all your contributions over these years.

isxek 11y ago
Thanks for starting Mercurial.

nailer 11y ago

hg could be 20% better than git. For the sake of the arugment, let's say it is. git's network effects mean hg needs to be 1000% better than git to replace it (much like git replaced svn, svn replaced cvs, and cvs replaced rcs).

restalis 11y ago
If people would judge a tool on its technical merits, that may be true. However, a lot of people that adopted git hardly needed/used git's improvements (in their one man projects).
umanwizard 11y ago
There are tons of companies using mercurial including some of the biggest ones. It's not really accurate to imply that Git won and Mercurial is dead.
- soperj 11y ago
  Yes, For instance, Java.
  - umanwizard 11y ago
    Facebook is another example :)
- amadvance 11y ago
  I consider the CPython switch from Mercurial to git the final declaration of victory. I still have to understand how CPython could miss the symbolic meaning of this decision.
  - mixmastamyk 11y ago
    It's probably more accurate to say they switched to github, but yes.
  - marcinkuzminski 11y ago

ChuckMcM 11y ago

This is a gutsy thing to do with a piece of software that has been part of your life for over a decade. Mad props to mpm. Up until Blekko I had pretty much been a perforce user (both at NetApp and at Google) and git was "that weird system you had to use to check in kernel changes". Blekko used Mercurial and I had no opinion as I had no experience. But over the years using hg at work and then starting up a github account to learn git, I saw the writing on the wall. Hg was the betamax of source code management systems. Clean, elegant, reliable, and not mainstream.

pjmlp 11y ago

I loved Mercurial, but just like with Wirth languages, I seem be on the wrong side of the mainstream flow. Thanks for Mercurial!

oscarcardoso 11y ago

If you ever see this, Thank you Matt. It helped me a lot to get away from subversion by working with hg at the same time.

indygreg2 11y ago

10+ years is a long time to steward a project. Most projects don't even live that long! Transitioning away after 10+ years is a sign of several positive things: * Creating a successful project that lasts 10+ years * Having the perseverance, patience, and willpower to guide that project for its lifetime * Creating a healthy community whom you are able to transition day-to-day responsibility of that project to Matt has accomplished something that most of us never will. I'm envious of what he has accomplished and that he is able to walk away from a healthy and successful project. Truly a remarkable accomplishment.

22klinda 11y ago

I've used Mercurial on Bitbucket in the past and loved it. Very thank you for your hard workd, Matt. Too bad that git is on everywhere now.

dhimes 11y ago

Thank you, Matt. hg is still my choice in source control. It's the only one I really use.

bedros 11y ago

I talked with an engineer from a fortune 500 tech company and they chose git over other vcs because they could have permission control; they have sensitive sub project who needs only a small set of engineers with permission to access it, but that subproject/module is part of a bigger project that everyone has access to. I personally prefer HG over git and use it for my own personal projects, hosted on my own redmine server. I tried bitbucket, and github; the latter have s superior interface to bitbucket. which I believe why people picked github over bitbucket

dochtman 11y ago

I was a Mercurial crew member for a few years (2008 to I don't know) and was very happy to be able to learn from Matt in his role as BDFL. His principled stance against layering violations and his policy to require really small commits still influence my coding every day. I hope he finds something new to give him satisfaction/joy!

tonfa 11y ago
+1, working with Matt was also extremely formative, I learned a lot of best practices during those years.
ufo 11y ago
What do you mean by "layering violations"?

stevelosh 11y ago

I've only contributed a few patches to Mercurial but meeting Matt and learning from him (mostly on the HG mailing lists) has taught me a lot. He's influenced how I think about and work with code at a really basic level. I wish him the best in whatever he decides to do.

krupan 11y ago

I'm really surprised by the "git won" mentality that manifests in any discussion of mercurial as of late. It makes no sense. We don't decare "winners" with other tools we use. Do we? Why are we all playing with new programming languages when C won? Or maybe C++ won? Or Java? Did emacs or vim win? Speaking of text, did ASCII win? Which code review tool won? How about continuous integration tools? or build tools? I mean, make won, right? None of us just pick the most widely used tool or programming language and say, "there can only be one" and then stop trying new things. Why are we doing this with version control?

Avshalom 11y ago
While emacs and vim are still duking it out people are CONSTANTLY defaulting to or arguing the case for this or that because "the right tool for the job" 90% of the time means "the tool the community supports for my problem"
slapresta 11y ago
Code collaboration tools have a strong network effect due to them being ultimately social tools, and we expect categories affected by the network effect to have winner/losers mechanics. Of course, they don't actually have to, but it's a common expectation and a common outcome. For equivalents to "code collaboration tools", instead of "programming languages", "text editors" and "build tools", try "social networks" (Facebook won, MySpace lost), "network protocols" (HTTP won, FTP and Gopher lost) or "spoken languages" (English won)
- krupan 11y ago
  It seems to me that programming languages have far stronger network effects than any other example you or I are throwing out. If one project uses git and another mercurial and they want to work together, there are ways (hg-git, plain old patches). Try incorporating some java code in a ruby project, however. No possible way that is going to fly. Yet, we (at least the hacker news crowd) haven't declared any language as "winner". I really hope version control does not stagnate at git.

yeukhon 11y ago

I did a project on integrating Mercurial with Mongo before, and I have to say being a Python developer I didn't have too much difficulty in figuring the right API, although the documentation is not so great. The code itself uses a lot of abbreviations which you have to really be patient to get familiar. The Mercurial model [1] is a pleasant read for a couple train ride (read it a few times I encourage). Others have done amazing things with hg too, like making hg available in Javascript (now an abandon project). Mercurial is actually very easy to use. However, it didn't have the exact lightweight concept of git branch until they implemented bookmark a few years ago. I don't remember the limitation of bookmarks now it has been a few years since I used Mercurial... I too thank Matt and core developers working on Mercurial. One thing I feel Matt and developers need to address is hosting hg on PyPI infrastructure instead of redirecting to their own server. From time to time the server wouldn't deliver anything and it was frustrating to see our builds fail (of course some say you should have cached the build and not hitting Mercurial server every day). [1]: https://www.mercurial-scm.org/wiki/Presentations?action=AttachFile&do=get&target=ols-mercurial-paper.pdf https://www.mercurial-scm.org/wiki/Presentations?action=Atta...

durin42 11y ago
We've been uploading to PyPI as part of our release process for quite some time, and our own server is hosted on public infra now instead of on a privately managed machine. :)

acveilleux 11y ago

I believe that Mercurial's greatest flaw is that it is too damn easy to use. Since you don't have to wrap your head around it so damn much to use it, it seems weak, like if it was only slightly better than subversion. The truth is different and Mercurial is roughly as capable as git but it's easy to miss Mercurial's power where as Git rubs your face in it (less so these days but early on, it was a brain f* to my CVS trained brain.)

harry8 11y ago

You find yourself in a realm where hackers don't branch and use svn with no experience of distributed source control. hg is so much your friend here. They will actually probably get over the switch hump and use it. git that hump is much bigger and more arduous. Git is great, I like it. When you want to drag the team with you who aren't already sold, just go straight to hg every time. You're hacker, you can use either effectively and both are excellent tools.

anarazel 11y ago

I think hg was/is important, to provide competition to git. But I don't really understand all the people arguing that hg is so much easier to use, and so much cleaner. Sure, in the first few years that was true, and there's architecturally better choices (not a mess of scripts, embeddable as library). But from a day to day usage, hg seems worse to me. And that includes the documentation, something that really surprised me after I had to restart using hg a year or so back. The whole thing how hard it is to actually get rid of branches (no, I do not want to merge that branch. Yes, I don't want any central record anymore. No, I don't want to ssh into the remote box. Uh....), really bugged me. So does the need, slowly abating, to activate a lot of random plugins to get functionality that git had for years (pagers, incremental add, staging area, ...). But I very well, and I actually mean that, might just be mind warped by having used git so long and so continually that I just don't see the problems anymore and it just seems easier. I do remember some initial difficulties understanding it, but that was in the quite early days...

antonyme 11y ago

Mercurial has to be one of the best examples of incredibly high quality Software Engineering out there. It is very well-designed, reliable, fast, easy to use, well-documented and has a great community behind it. Matt deserves huge kudos for his enormous effort and commitment over the years. And like a true gentleman, he is leaving in style to ensure the transition is smooth.