11 ms·

Mercurial: Onward and upward

167 points by gitdude 11y ago

krupan 11y ago
I love all the new things the mercurial developers are willing to experiment with and try out. It seems the (sometimes maligned) plugin system that mercurial uses makes this easy. It's been really interesting to see how our (mercurial developers' and users') ideas about how distributed version control can and should be used have morphed and changed over the years. I remember when mercurial's branching recommendation was to have a clone per branch and when we all hated the idea of modifying our history. Now mercurial supports 4 different branching models and has excellent history editing support with commit --amend, rebase, histedit, and changeset evolution. I'm excited to play with the other new features that are coming.
pbreit 11y ago
It seems to work OK but monthly releases for version control software scares the heck out of me.
- jordigh 11y ago
  Don't be scared. Mercurial is very conservative about what a new release can do. There are lots of rules, and they are treated very seriously: http://www.mercurial-scm.org/wiki/CompatibilityRules http://www.mercurial-scm.org/wiki/CompatibilityRules
- TillE 11y ago
  I've had zero problems with Mercurial, including communicating with a server running a years-old version. If you look through the changelogs, you'll find that it's mostly adding a lot of optional features, not frantically fixing bugs in the core.
- _random_ 11y ago
  http://en.wikipedia.org/wiki/Continuous_delivery http://en.wikipedia.org/wiki/Continuous_delivery
- SwellJoe 11y ago
  So, you would prefer one big release every year with hundreds of changes? I will take small, incremental improvements over massive upgrades always. If something goes wrong in a monthly release, the change log is short enough for me to read every item and probably figure it out in a few minutes. I cannot think of any benefit to a slow release cycle with large changes bunched up into versions, and consider it a major negative when I am choosing software (I'm currently upgrading to Drupal 7 from 6 and its been almost funny how much of a disaster it's been). There's a reason Chrome and Firefox and Manny others do rapid rolling releases. It simply delivers better software faster and with less likelihood of catastrophic problems. Small changesets are just easier to fit into a human mind.
jordigh 11y ago
I'm very excited about bitbucket improving their hg support. The blog poster, Sean Farley, was previously working on Kallithea before going to work at Bitbucket. I met him during Pycon. From my understanding, he's still allowed to work on Kallithea. I'm excited about Mercurial's future. There are so many great things coming out. New ways to handle branching, shallow and narrow clones, an experimental interface for running hg over a git store...
- smacktoward 11y ago
  > an experimental interface for running hg over a git store It would make me very happy to be able to interact with Git repos through an interface that didn't make me want to kill myself with a rusty railroad spike.
  - jordigh 11y ago
    Well, if you are feeling adventurous, https://bitbucket.org/durin42/hgit https://bitbucket.org/durin42/hgit
- Macha 11y ago
  What's wrong with https://hg-git.github.io/ https://hg-git.github.io/ ? I gather the difference is that hg-git has a mercurial repo locally and maps hg bookmarks to git branches and commits at push/pull time, while it seems like this experimental interface is using the HG UI against a git repo locally, but why is this better?
  - jordigh 11y ago
    hg-git converts git repos into hg repos, while hgit lets you do `hg commit` or `git commit` on the exact same git repo, with the exact same hashes. Why is it better? Converting a git repo to hg takes a long time, you need a way to translate hashes back and forth between the two repos, bookmarks in hg are not exactly the same as branches in git. Or in the words of Cervantes, "translation from one language into another [...] is like gazing at a Flemish tapestry with the wrong side out."
ngoldbaum 11y ago
I'm excited to see improved mercurial support at bitbucket in the near future. While bitbucket's support for mercurial goes back many years, mercurial itself has evolved a lot in the meantime, and bitbucket has been focusing more on support for git for several years now. At the very least, I'm glad they have someone on staff who cares about mercurial so new features don't break things for mercurial users.
krylon 11y ago
Mercurial was a real eye-opener. Before a friend basically made me try Mercurial, I was using Subversion for managing my private projects, and it was not exactly fun. Especially when I was working on my laptop (netbook, actually, but that is totally OT), away from home, without access to the server. Mercurial made VCS fun. I recently moved on to Fossil, because I do like the integrated wiki and ticket system for smallish projects, but without Mercurial I never would have gotten there. I also like Mercurial's hooks. I am not sure if other DCVS support that, but hooks are great. (Fossil doesn't appear to have them)
- stevekemp 11y ago
  I agree that hooks are awesome, I use numerous hooks with git to do everything from syntax check Perl scripts, to uploading DNS zones.
- masklinn 11y ago
  > I also like Mercurial's hooks. I am not sure if other DCVS support that Git has various hooks (client and server), Darcs I do not know.
j_baker 11y ago
> These include the concept of changeset evolution coming to life and the announcement of both Facebook and Google choosing Mercurial over Git. Perhaps this is true for Facebook. But I can say that Google most certainly does not use Hg over Git. The Go source code used to be under Hg, but they've recently migrated to git.
- Mathiasdm 11y ago
  I'm guessing it depends from project to project? There are several Google developers contributing to Mercurial.
  - cdibona 11y ago
    If you look at development at Google, you'll see most people on a perforce derived repo system , then groups like Android, chrome, Etc on git, then basically very few teams using Mercurial. We do have some hg contributors like augie, but we have way more git contributors, includes git project Lead Junio.
- belak 11y ago
  I think one of the largest reasons for Go moving to github is that most of their community already develops there. They cited that as a reason here: https://groups.google.com/forum/#!topic/golang-dev/sckirqOWepg%5B1-25%5D https://groups.google.com/forum/#!topic/golang-dev/sckirqOWe... Also, just because they're using git for public projects doesn't rule out that they may be using mercurial internally. Google pays a number of people to work on mercurial... I'm not sure if that's the same for git.
- laurencerowe 11y ago
  For smaller projects (up to the size of the Linux Kernal) it seems Git and Mercurial are pretty interchangeable so people go with Git and GitHub due to network effects. Presumably this is all about replacing the massive Perforce repository for Google's production codebase using similar Mercurial scaling tricks as Facebook. https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...
pseudonym 11y ago
I started with and loved Mercurial as a DVCS, and it still has some QoL commands that Git requires some hoop-jumping to get at, but ultimately the deciding factor was the inability to permanently delete branches. Since branched dev work would fairly regularly have generic names or the names of the developer working on it, it would always end up being forked and merged instead of branched and merged, which led to a ridiculous number of headaches in our build system. We still use mercurial for most of our repositories just because they're dated and not likely to see more than a handful of commits a year, but most of our active development work has already converted to git.
- sampo 11y ago
  > inability to permanently delete branches If your workflow fits better with git-style branches, you should use Mercurial bookmarks, not Mercurial named branches. Mercurial even tells you: (branches are permanent and global, did you want a bookmark?) every time you create a named branch.
  - loxs 11y ago
    Well, IMHO, nowadays this classifies as bad design. It may have been the better design, but currently git's nomenclature is the standard and not complying to it will only hurt mercurial.
    - ngoldbaum 11y ago
      Mercurial and git were initially released within a couple of weeks of each other. To change terminology now would break ten years of backward compatibility.
      - loxs 11y ago
        I understand that, but my point is still valid. Mercurial is not "guilty" about this, but certainly suffers
  - Skinney 11y ago
sergiotapia 11y ago
Key paragraph for us mere mortals: "In my time with Mercurial, I have seen it grow in fascinating ways. These include the concept of changeset evolution coming to life and the announcement of both Facebook and Google choosing Mercurial over Git. The future of Mercurial is that of scalability and because of that, I believe the best days of Mercurial are ahead." Is it time to give Mercurial another shot? I first migrated from SVN to Mercurial way back when - but after the massive increase in Git's popularity I bit the bullet and switched. What does Mercurial have over Git today?
- sampo 11y ago
  > What does Mercurial have over Git today? There exists no easy tutorial, that takes a beginner up to speed with git. You need to read almost a book length of material and familiarize yourself with some of the git's internals, and to some extent build your own mental model of git by experimentation, before you can use git without regular wtf-moments. Well, there is also no tutorial that would provide the same level of understanding of the internals of Mercurial, but by some magic it seems that beginners do not need to acquire the same depth of understanding of Mercurial that they need to acquire about git, before they can start to work with Mercurial without wtf's and frustration. Once you have a solid understanding of how DVCS's work, you can use both Mercurial and git without problems. But if you need to bring a bunch of beginners up to speed, somehow it goes easier with Mercurial. At least, this is my experience. If someone else has experience in training teams to start using a DVCS, and has compared both git and Mercurial, and has opposite experiences, I'd be interested to hear.
  - tjradcliffe 11y ago
    I have had the same experience as you. I used git for a couple of years and definitely had regular wtf moments. Switched to Mercurial and they just went away. The complexity and counter-intuitive (to me, at least) nature of git's model was a major barrier to entry. I still use git now and then because github is so popular, but for a small team on a moderate-sized project I really prefer Mercurial for its ease of use.
  - Touche 11y ago
imakesnowflakes 11y ago
Mercurial user for the past 6 or 7 years here. I cling to Mercurial despite people asking me to move some of my side projects (nothing substantial though) to git and github. I refuse to do that out of principle. I think Mercurial should have taken the place of git as the widely used DVCS. And I try to be THAT change I want to see. That being said, It would be great if someone can get the hg-git plugin to work seamlessly with newer versions of Mercurial on Windows and Linux, so that I can keep using Mercurial even if a project I am involved in uses git.
- LukeHoersten 11y ago
  Same story here. I learned both Git and HG circa 2007 and decided HG had a more pure DVCS model. I still believe that's the case and still use HG. When I interact with GitHub I use hg-git. Long time Git users: I strongly encourage you to try Mercurial.
  - DigitalJack 11y ago
    Every time I try HG, I find that to do what I want I have to get a bunch of plugins. When I use a VCS, I want to know that I'm using the same commands as everyone else, so that we are all speaking the same language. Most of the git commands I use are about as straight forward and simple as they could be. If ever I manage to screw something up, the archeology commands I end up using are obtuse, but it's rare that I need them. And I'm glad they are there when I do.
    - kyrra 11y ago
      Are they plugins that you just enable in the conf file? If so, all extensions that ship with mercurial are fully supported features. They just disable parts of the cli that can be dangerous or are less commonly used. If you are having to download 3rd party extensions, then that's a different problem.
- swpalmer 11y ago
  Totally agree. Mercurial really is the product that deserves the spot that Git has claimed in terms of being the defacto DVCS. It's generally easier to use, well supported, and more intuitive. The good thing is that there is still a healthy competition out there to push ease of use and features forward. I think promoting Mercurial to help it gain market share is important. You don't have to suffer through Git!
kasabali 11y ago
> The future of Mercurial is that of scalability and because of that, I believe the best days of Mercurial are ahead. That sounded to me like Mercurial has started to carve their own niche after losing the popularity war to git (maybe just my wishful thinking?), and this may have very good outcomes since currently all scalable mainstream vcs choices are centralized. Git developers showed they're hardly interested in this area, and Mercurial have had some head start with the contributions from Facebook. I don't think anybody would object it if we had a free dvcs that can respond to very high scalability needs without hacking around its deficiencies. This is the point where Mercurial project should reconsider its priorities and even put some of their current priorities into back seat if that's what it gets to achieve their new goals with no compromises. My best wishes for Mercurial, go for it!
ptype 11y ago
I wish Bitbucket would invest some time implementing 2FA. It's 2015. https://bitbucket.org/site/master/issue/5811/support-two-factor-authentication-bb-7016 https://bitbucket.org/site/master/issue/5811/support-two-fac...

167 points by gitdude 11y ago

I love all the new things the mercurial developers are willing to experiment with and try out. It seems the (sometimes maligned) plugin system that mercurial uses makes this easy. It's been really interesting to see how our (mercurial developers' and users') ideas about how distributed version control can and should be used have morphed and changed over the years. I remember when mercurial's branching recommendation was to have a clone per branch and when we all hated the idea of modifying our history. Now mercurial supports 4 different branching models and has excellent history editing support with commit --amend, rebase, histedit, and changeset evolution. I'm excited to play with the other new features that are coming.

pbreit 11y ago

It seems to work OK but monthly releases for version control software scares the heck out of me.

jordigh 11y ago
Don't be scared. Mercurial is very conservative about what a new release can do. There are lots of rules, and they are treated very seriously: http://www.mercurial-scm.org/wiki/CompatibilityRules http://www.mercurial-scm.org/wiki/CompatibilityRules
TillE 11y ago
I've had zero problems with Mercurial, including communicating with a server running a years-old version. If you look through the changelogs, you'll find that it's mostly adding a lot of optional features, not frantically fixing bugs in the core.
_random_ 11y ago
http://en.wikipedia.org/wiki/Continuous_delivery http://en.wikipedia.org/wiki/Continuous_delivery
SwellJoe 11y ago
So, you would prefer one big release every year with hundreds of changes? I will take small, incremental improvements over massive upgrades always. If something goes wrong in a monthly release, the change log is short enough for me to read every item and probably figure it out in a few minutes. I cannot think of any benefit to a slow release cycle with large changes bunched up into versions, and consider it a major negative when I am choosing software (I'm currently upgrading to Drupal 7 from 6 and its been almost funny how much of a disaster it's been). There's a reason Chrome and Firefox and Manny others do rapid rolling releases. It simply delivers better software faster and with less likelihood of catastrophic problems. Small changesets are just easier to fit into a human mind.

jordigh 11y ago

I'm very excited about bitbucket improving their hg support. The blog poster, Sean Farley, was previously working on Kallithea before going to work at Bitbucket. I met him during Pycon. From my understanding, he's still allowed to work on Kallithea. I'm excited about Mercurial's future. There are so many great things coming out. New ways to handle branching, shallow and narrow clones, an experimental interface for running hg over a git store...

smacktoward 11y ago
> an experimental interface for running hg over a git store It would make me very happy to be able to interact with Git repos through an interface that didn't make me want to kill myself with a rusty railroad spike.
- jordigh 11y ago
  Well, if you are feeling adventurous, https://bitbucket.org/durin42/hgit https://bitbucket.org/durin42/hgit
Macha 11y ago
What's wrong with https://hg-git.github.io/ https://hg-git.github.io/ ? I gather the difference is that hg-git has a mercurial repo locally and maps hg bookmarks to git branches and commits at push/pull time, while it seems like this experimental interface is using the HG UI against a git repo locally, but why is this better?
- jordigh 11y ago
  hg-git converts git repos into hg repos, while hgit lets you do `hg commit` or `git commit` on the exact same git repo, with the exact same hashes. Why is it better? Converting a git repo to hg takes a long time, you need a way to translate hashes back and forth between the two repos, bookmarks in hg are not exactly the same as branches in git. Or in the words of Cervantes, "translation from one language into another [...] is like gazing at a Flemish tapestry with the wrong side out."

ngoldbaum 11y ago

I'm excited to see improved mercurial support at bitbucket in the near future. While bitbucket's support for mercurial goes back many years, mercurial itself has evolved a lot in the meantime, and bitbucket has been focusing more on support for git for several years now. At the very least, I'm glad they have someone on staff who cares about mercurial so new features don't break things for mercurial users.

krylon 11y ago

Mercurial was a real eye-opener. Before a friend basically made me try Mercurial, I was using Subversion for managing my private projects, and it was not exactly fun. Especially when I was working on my laptop (netbook, actually, but that is totally OT), away from home, without access to the server. Mercurial made VCS fun. I recently moved on to Fossil, because I do like the integrated wiki and ticket system for smallish projects, but without Mercurial I never would have gotten there. I also like Mercurial's hooks. I am not sure if other DCVS support that, but hooks are great. (Fossil doesn't appear to have them)

stevekemp 11y ago
I agree that hooks are awesome, I use numerous hooks with git to do everything from syntax check Perl scripts, to uploading DNS zones.
masklinn 11y ago
> I also like Mercurial's hooks. I am not sure if other DCVS support that Git has various hooks (client and server), Darcs I do not know.

j_baker 11y ago

> These include the concept of changeset evolution coming to life and the announcement of both Facebook and Google choosing Mercurial over Git. Perhaps this is true for Facebook. But I can say that Google most certainly does not use Hg over Git. The Go source code used to be under Hg, but they've recently migrated to git.

Mathiasdm 11y ago
I'm guessing it depends from project to project? There are several Google developers contributing to Mercurial.
- cdibona 11y ago
  If you look at development at Google, you'll see most people on a perforce derived repo system , then groups like Android, chrome, Etc on git, then basically very few teams using Mercurial. We do have some hg contributors like augie, but we have way more git contributors, includes git project Lead Junio.
belak 11y ago
I think one of the largest reasons for Go moving to github is that most of their community already develops there. They cited that as a reason here: https://groups.google.com/forum/#!topic/golang-dev/sckirqOWepg%5B1-25%5D https://groups.google.com/forum/#!topic/golang-dev/sckirqOWe... Also, just because they're using git for public projects doesn't rule out that they may be using mercurial internally. Google pays a number of people to work on mercurial... I'm not sure if that's the same for git.
laurencerowe 11y ago
For smaller projects (up to the size of the Linux Kernal) it seems Git and Mercurial are pretty interchangeable so people go with Git and GitHub due to network effects. Presumably this is all about replacing the massive Perforce repository for Google's production codebase using similar Mercurial scaling tricks as Facebook. https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...

pseudonym 11y ago

I started with and loved Mercurial as a DVCS, and it still has some QoL commands that Git requires some hoop-jumping to get at, but ultimately the deciding factor was the inability to permanently delete branches. Since branched dev work would fairly regularly have generic names or the names of the developer working on it, it would always end up being forked and merged instead of branched and merged, which led to a ridiculous number of headaches in our build system. We still use mercurial for most of our repositories just because they're dated and not likely to see more than a handful of commits a year, but most of our active development work has already converted to git.

sampo 11y ago
> inability to permanently delete branches If your workflow fits better with git-style branches, you should use Mercurial bookmarks, not Mercurial named branches. Mercurial even tells you: (branches are permanent and global, did you want a bookmark?) every time you create a named branch.
- loxs 11y ago
  Well, IMHO, nowadays this classifies as bad design. It may have been the better design, but currently git's nomenclature is the standard and not complying to it will only hurt mercurial.
  - ngoldbaum 11y ago
    Mercurial and git were initially released within a couple of weeks of each other. To change terminology now would break ten years of backward compatibility.
    - loxs 11y ago
      I understand that, but my point is still valid. Mercurial is not "guilty" about this, but certainly suffers
- Skinney 11y ago

sergiotapia 11y ago

Key paragraph for us mere mortals: "In my time with Mercurial, I have seen it grow in fascinating ways. These include the concept of changeset evolution coming to life and the announcement of both Facebook and Google choosing Mercurial over Git. The future of Mercurial is that of scalability and because of that, I believe the best days of Mercurial are ahead." Is it time to give Mercurial another shot? I first migrated from SVN to Mercurial way back when - but after the massive increase in Git's popularity I bit the bullet and switched. What does Mercurial have over Git today?

sampo 11y ago
> What does Mercurial have over Git today? There exists no easy tutorial, that takes a beginner up to speed with git. You need to read almost a book length of material and familiarize yourself with some of the git's internals, and to some extent build your own mental model of git by experimentation, before you can use git without regular wtf-moments. Well, there is also no tutorial that would provide the same level of understanding of the internals of Mercurial, but by some magic it seems that beginners do not need to acquire the same depth of understanding of Mercurial that they need to acquire about git, before they can start to work with Mercurial without wtf's and frustration. Once you have a solid understanding of how DVCS's work, you can use both Mercurial and git without problems. But if you need to bring a bunch of beginners up to speed, somehow it goes easier with Mercurial. At least, this is my experience. If someone else has experience in training teams to start using a DVCS, and has compared both git and Mercurial, and has opposite experiences, I'd be interested to hear.
- tjradcliffe 11y ago
  I have had the same experience as you. I used git for a couple of years and definitely had regular wtf moments. Switched to Mercurial and they just went away. The complexity and counter-intuitive (to me, at least) nature of git's model was a major barrier to entry. I still use git now and then because github is so popular, but for a small team on a moderate-sized project I really prefer Mercurial for its ease of use.
- Touche 11y ago

imakesnowflakes 11y ago

Mercurial user for the past 6 or 7 years here. I cling to Mercurial despite people asking me to move some of my side projects (nothing substantial though) to git and github. I refuse to do that out of principle. I think Mercurial should have taken the place of git as the widely used DVCS. And I try to be THAT change I want to see. That being said, It would be great if someone can get the hg-git plugin to work seamlessly with newer versions of Mercurial on Windows and Linux, so that I can keep using Mercurial even if a project I am involved in uses git.

LukeHoersten 11y ago
Same story here. I learned both Git and HG circa 2007 and decided HG had a more pure DVCS model. I still believe that's the case and still use HG. When I interact with GitHub I use hg-git. Long time Git users: I strongly encourage you to try Mercurial.
- DigitalJack 11y ago
  Every time I try HG, I find that to do what I want I have to get a bunch of plugins. When I use a VCS, I want to know that I'm using the same commands as everyone else, so that we are all speaking the same language. Most of the git commands I use are about as straight forward and simple as they could be. If ever I manage to screw something up, the archeology commands I end up using are obtuse, but it's rare that I need them. And I'm glad they are there when I do.
  - kyrra 11y ago
    Are they plugins that you just enable in the conf file? If so, all extensions that ship with mercurial are fully supported features. They just disable parts of the cli that can be dangerous or are less commonly used. If you are having to download 3rd party extensions, then that's a different problem.
swpalmer 11y ago
Totally agree. Mercurial really is the product that deserves the spot that Git has claimed in terms of being the defacto DVCS. It's generally easier to use, well supported, and more intuitive. The good thing is that there is still a healthy competition out there to push ease of use and features forward. I think promoting Mercurial to help it gain market share is important. You don't have to suffer through Git!

kasabali 11y ago

> The future of Mercurial is that of scalability and because of that, I believe the best days of Mercurial are ahead. That sounded to me like Mercurial has started to carve their own niche after losing the popularity war to git (maybe just my wishful thinking?), and this may have very good outcomes since currently all scalable mainstream vcs choices are centralized. Git developers showed they're hardly interested in this area, and Mercurial have had some head start with the contributions from Facebook. I don't think anybody would object it if we had a free dvcs that can respond to very high scalability needs without hacking around its deficiencies. This is the point where Mercurial project should reconsider its priorities and even put some of their current priorities into back seat if that's what it gets to achieve their new goals with no compromises. My best wishes for Mercurial, go for it!

ptype 11y ago

I wish Bitbucket would invest some time implementing 2FA. It's 2015. https://bitbucket.org/site/master/issue/5811/support-two-factor-authentication-bb-7016 https://bitbucket.org/site/master/issue/5811/support-two-fac...