[HN Gopher] I kind of killed Mercurial at Mozilla
___________________________________________________________________
I kind of killed Mercurial at Mozilla
Author : sylvestre
Score : 95 points
Date : 2023-11-21 20:16 UTC (2 hours ago)
(HTM) web link (glandium.org)
(TXT) w3m dump (glandium.org)
| galkk wrote:
| Interesting, given that Google and Facebook [2], at least,
| eventually moved to have their repositories offered via Mercurial
| interface, instead of git.
|
| I also would expect that Github eventually will also offer
| mercurial repos.
|
| p.s. And let's not talk about abomination that is GitLFS
| (starting from the fact that it requires separate subcommand).
|
| [2] https://engineering.fb.com/2014/01/07/core-infra/scaling-
| mer...
| numbsafari wrote:
| That's 2014 vintage. Is it still true?
| slimginz wrote:
| Yup! In fact Meta's implementation is open sourced as Sapling
| SCM and includes both Mercurial and Git support[1].
| Internally the main repository use Mercurial although I
| believe a few legacy projects still use git.
|
| [1] https://sapling-scm.com/
| explodingcamera wrote:
| From the documentation, it seems like there is 0 mercurial
| support. It's its own separate version control system that
| diverged years ago. You can either use the sapling scm
| client or git.
| pineapple_sauce wrote:
| Meta uses https://github.com/facebook/sapling see:
| https://engineering.fb.com/2022/11/15/open-source/sapling-
| so...
|
| It's an extension from Mercurial as the blog post states.
| lutoma wrote:
| > I also would expect that Github eventually will also offer
| mercurial repos.
|
| How come? That seems highly unlikely to me, especially when you
| consider that one of their larger competitors (Bitbucket) had
| Mercurial support for a long time and then removed it.
| mrighele wrote:
| In fact Bitbucket started as a Mercurial hosting service,
| then added Git support, then dropped Mercurial.
|
| From when they dropped Mercurial in 2020 [1]:
|
| "Yesterday marked an end of an era for Mercurial users, as
| Bitbucket announced to no longer support Mercurial
| repositories after May 2020. Bitbucket, owned by Atlassian,
| is a web-based version control repository hosting service,
| for source code and development projects. It has used
| Mercurial since the beginning in 2008 and then Git since
| October 2011."
|
| [1] https://hub.packtpub.com/bitbucket-to-no-longer-support-
| merc...
| Blackthorn wrote:
| That change was so dumb. Mercurial support was the bit that
| put them as something different from github. Once they didn't
| have it anymore, why would anyone use them at all?
| the_mitsuhiko wrote:
| I'm sure they knew what they did. They probably primarily
| had git users on the service, and the motivation to use
| Bitbucket is most likely because you already pay for other
| Atlassian products.
| jeremyjh wrote:
| So since you are knowledgeable about the fact that this
| decision was "dumb", you must also know approximately what
| proportion of their users were dependent on hg for their
| workflow ? My priors would put it at less - likely far less
| - than 1%. But please share your knowledge.
| gmueckl wrote:
| Not true. I looked at the complete list of hosted
| projects on Bitbucket just when it was shut down and I
| recall that at least 10% of all repos ever created on
| Bitbucket were hg repos.
| ayhanfuat wrote:
| In the announcement they mentioned that less than 1% of
| new users were choosing hg. It was probably slightly
| higher for old users.
|
| > In fact, Mercurial usage on Bitbucket is steadily
| declining, and the percentage of new Bitbucket users
| choosing Mercurial has fallen to less than 1%.
|
| https://bitbucket.org/blog/sunsetting-mercurial-support-
| in-b...
| culi wrote:
| Still seems near-sighted. If someone started a new
| mercurial project what would they choose to host it on?
| BitBucket basically automatically wins new users by being
| the only player in the game
| tsimionescu wrote:
| One huge advantage for them compared to GitHub is that they
| offer an on-prem version. That is much more relevant than
| Hg support of all things.
|
| It also gets bundled with Jira and Confluence.
| gmueckl wrote:
| The hosted Bitbucket and Bitbucket Server (formerly
| called Stash) only share the name. They are completely
| different implementations and Bitbucket Server never
| supported Mercurial.
| wmf wrote:
| FB/Meta replaced Mercurial with Sapling which is git-
| compatible: https://engineering.fb.com/2022/11/15/open-
| source/sapling-so...
|
| Mercurial is over.
| LAC-Tech wrote:
| > Mercurial is over.
|
| I mean to be fair so is Firefox
| 1letterunixname wrote:
| Meta's fork/rewrite of hg, Sapling hasn't gone anywhere yet
| because it needs EdenFS and Mononoke that aren't yet/maybe
| never FOSS. It's only called hg internally because of legacy
| reasons but it's completely different.
|
| Microsoft hired a git maintainer to improve large repo
| performance and so it's better than it was.
| Shish2k wrote:
| I've been using the sapling CLI as my frontend with github
| as my backend and finding it quite delightful - all the UX
| niceness from mercurial (and then some), while still being
| totally compatible with the rest of my team :)
| aseipp wrote:
| Sapling can use Mononoke, but it can also use Git
| repositories as the underlying storage layer with no server
| at all, and it does so by default in the OSS build. You can
| use it just fine with GitHub today, but there are rough
| edges.
|
| My understanding is that the work to support OSS builds of
| Mononoke+EdenFS is happening, but there's no exact timeline
| right now because (from what I can tell) they basically
| have to abstract out and write new production storage
| components for the metadata/object layer, as they can't use
| their internal ones, obviously.
| fmajid wrote:
| Git has a lot of warts, but if I were to pick an alternative
| it would be Fossil, not Mercurial.
|
| I believe Meta's implementation includes server components
| (Mononoke) that were not open-sourced, or at least not
| buildable without closed-source dependencies. Same with
| Microsoft's fork of git that relies on a virtual filesystem,
| but that one is open-sourced, if for Windows, not Linux.
| petre wrote:
| Mercurial is dead unfortunately. It's been stuck on Python
| 2. The CLI was saner than Git but it needed Python, which
| helped with our (better) decision to pick Fossil instead.
| This was 11 years ago. It's been great, it has everything
| you need in a single executable which can be statically
| compiled.
| rbehrends wrote:
| Mercurial runs on Python 3 just fine and has been for a
| while. In fact, starting with Mercurial 6.2 (from July
| 2022), Python 2 is no longer supported [1].
|
| [1] https://wiki.mercurial-scm.org/Release6.2
| alwillis wrote:
| > Mercurial is dead unfortunately. It's been stuck on
| Python 2.
|
| Mercurial adopted Python 3 a while ago. Not to mention,
| huge chunks of it have been rewritten in Rust.
|
| Mercurial has continued to get new features like
| Changeset Evolution [1] that once you use it, you wonder
| why all version control systems don't have it.
|
| [1]: https://www.mercurial-scm.org/doc/evolution/
| rbehrends wrote:
| As somebody who has actually been using Sapling (because it
| provides a much saner UI and mental model than git), the git
| compatibility of Sapling is at best so-so. It feels more like
| a stopgap solution while they're evolving their own backend
| (which I'm pretty sure they use internally, because git just
| doesn't scale to FB monorepo size and doesn't support their
| rebase-on-push operation). LFS flat-out doesn't work with
| Sapling. Force pushing after an amend or rebase is still
| cumbersome, because you need to explicitly specify (again)
| the branch you are pushing to. And I'm not sure how bad the
| file descriptor problem still is that you have (had?) with
| large repos or submodules [1]; there was a new release
| recently, but I haven't actually stress-tested that.
|
| [1] At least some of that may be due to file descriptor
| leaks: https://github.com/facebook/sapling/issues/464
| billllll wrote:
| Bitbucket dropped Mercurial support in 2020:
| https://bitbucket.org/blog/sunsetting-mercurial-support-in-b...
|
| I just don't think there is good RoI for implementing Mercurial
| support. It really isn't about the interface (which I think
| most people agree hg is better than git). It's just the network
| effect: most projects use git so everybody learns git and they
| don't want to learn another tool even if it's better in some
| ways. At the end of the day, once you pay a higher upfront cost
| to learn the ~5 git invocations you need, your daily
| productivity between using git and hg is probably the same.
|
| Google and Facebook is different: they have a unique use-case
| and scale, and massive internal tooling teams supporting their
| use-cases. Also, as an employee, you're probably more open to
| different VCS systems because if you learn hg at Facebook,
| you're learning it on company time whereas if you learn for an
| open source project, you're learning it on your time.
| astrange wrote:
| I knew the guy who wanted Google Code to be Mercurial based; he
| pretty much just did it because he liked Python and therefore
| thought anything written in Python was good.
| aseipp wrote:
| Google currently uses a fork of Mercurial as the frontend to
| Piper, but there is work to replace it wholesale, eventually:
| https://github.com/martinvonz/jj
|
| (As a disclosure, I'm involved with and contribute to jj, but I
| don't work for or speak for Google in any way; the above
| statement is public knowledge.)
| culi wrote:
| Any comments about what it does better than git and
| mercurial?
| zabzonk wrote:
| i kind of wonder why there has never been an "hghub", given that
| i've always liked hg rather than git. but i guess it is the
| torvalds connection?
| nickcox wrote:
| There was bitbucket.
| rstarast wrote:
| I want to say bitbucket started out as this, at least my first
| repos there were hg.
| bluGill wrote:
| Because you never wrote it. The curse of open source.
|
| By the time github came about, git already had a lot more
| mindshare than hg. While hg wasn't yet clearly an also ran, it
| was clearly the less popular solution, and many open source
| tools started supporting git but either not supporting hg, or
| if they did it was an afterthought and often the maintainers
| broke something hg without noticing and then releasing with
| broken hg support.
| abound wrote:
| Sourcehut (sr.ht) has Mercurial support at hg.sr.ht
| lern_too_spel wrote:
| That was Bitbucket. https://bitbucket.org/blog/sunsetting-
| mercurial-support-in-b...
| Sparkyte wrote:
| Software unmaintained kills itself. I wouldn't feel all too bad
| if you found a different solution that fits your demand. To say
| one shoe fits all is silly.
| Yoric wrote:
| Snitched upon by his colleague, too!
|
| (hi glandium, sylvestre)
| sylvestre wrote:
| Coucou ;)
| lizzard wrote:
| Joining the party, that was a trip down memory lane!
| liveoneggs wrote:
| Mercurial has a quintessential "Rewrite it in rust!" page:
| https://wiki.mercurial-scm.org/OxidationPlan
| danking00 wrote:
| I've heard this point of view many times, but cannot find an
| extensive explanation of it. Could anyone elaborate on the issue
| with the GitHub review UI/UX?
|
| > I hate the GitHub review UI with a passion. At least, right
| now, GitHub PRs are not a viable option for Mozilla [...] the
| more general shortcomings in the review UI.
| steveklabnik wrote:
| I know people who express similar feelings. Usually it is
| shorthand for "I would prefer stacked diffs" or similar.
|
| Two blog posts I've seen people point at:
|
| * https://mitchellh.com/writing/github-changesets
|
| * https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/
| anyonecancode wrote:
| From the second article, a minor point but possibly helpful
| to other here, he contrasts doing everything in the terminal
| with stacked commits vs going to the Github UI. If people
| aren't aware, Github offers a cli tool[1]. I've been using it
| for a few months now and am finding it does make me more
| productive -- it's nice to be able to open up a PR directly
| from my terminal. I do still use the GH UI for a lot of
| things, but I'll often at least start in the terminal, and it
| also makes the transition from terminal to browser easy as
| many commands support the `--web` flag open up the right page
| for you (eg `gh repo view --web`).
|
| [1] https://cli.github.com/
| lima wrote:
| The CLI doesn't help with stacked commits, though. There's
| tools like spr[1] but none of them are anywhere as pleasant
| to use as Gerrit (or Phabricator, I guess).
|
| [1]: https://github.com/ejoffe/spr
| shepherdjerred wrote:
| I've found that Graphite [0] has solved this issue for me.
| It's makes the experience of shipping stacked diffs about the
| same as the CR tool within AWS
|
| [0]: https://graphite.dev/
| whoateallthepy wrote:
| One point: if you are re-reviewing, other platforms (e.g.
| Phabricator, Gerrit) have much more developed ways to compare
| changes relative to one another.
| sylvestre wrote:
| See https://news.ycombinator.com/item?id=37836932 by a Mozilla
| employee
| ge96 wrote:
| bitbucket is worse, reviewees can resolve reviewer's comments
| (github has this too turns out), after file changes, comments
| disappear
| AlotOfReading wrote:
| What's wrong with reviewees marking comments resolved? That
| allows anyone reading to see what issues are "open" or
| already addressed at a glance.
|
| Code review isn't adversarial, so it's not like the reviewee
| is closing comments to shove bad code through and they need
| approvals anyway.
| ge96 wrote:
| It's when they resolve it without verifying if their
| solution was good
| dllthomas wrote:
| One issue I was discussing with a colleague just the other day
| is that you cannot leave a comment on lines that are not "part
| of the diff" (changed or context), which is sometimes really
| useful for "see this thing over here".
| zoogeny wrote:
| I once worked with a guy who _hated_ Python. He also _hated_
| IntelliJ and did all of his programming in Eclipse. He _hated_
| MacOS and would only run old versions of Windows of Linux.
|
| What I found was that he was just sensitive to change. It took
| him awhile to get comfortable with something but as soon as he
| did he would from then on resist any change. Anything that was
| different to what he was used to he _hated_.
|
| In some sense, it makes sense. People should prefer processes
| over tools in many cases. If you have a process that works with
| one tool but doesn't work with a new tool then you might be
| better off sticking with the original tool. Broken processes
| can debilitate organizations.
|
| When people say "I hate X" often what they are really saying is
| "I have a process to do Y that works for me but tool X makes
| that process too difficult". The problem is they just say "I
| hate X" so you never really hear about the process Y which
| provides the context.
| lima wrote:
| GitHub PRs are both bad process (no stacking or per-commit
| review, incentivizes large changes, ...) and bad tool (no
| inter-diffs, noisy diffs, comments disappear through rebases,
| slow, ...).
| jeffbee wrote:
| Github review is good for either zero or one round of comments.
| After that you can't tell what the hell is going on. It has
| clearly been written by people who do not themselves practice
| code review. Compare and contrast with Gerrit, which remains
| usable after many rounds of comments, in both directions, and
| changes. Compare also Phabricator.
| CorrectHorseBat wrote:
| Linux kernel development never used cvs, I believe Linus thought
| it gives people brain damage and did just send around patches and
| tarballs
| glandium wrote:
| Linus never used CVS, but there was a CVS server and the
| community was using it.
| https://flosshub.org/sites/flosshub.org/files/127-131.pdf
| bananapub wrote:
| _parts_ of the community, if I recall correctly, and to be
| clear to everyone else since I 'm sure you know this:
|
| 1. linus didn't use version control at all, he just got
| patches emailed to him, then every now and then he'd publish
| a tarball and incremental patches (e.g. a 2.4.11-rc2 patch on
| top of 2.4.11-rc1) - the world had no visibility into his
| tree's development aside from the tarballs and inter-version
| patches he sent out
|
| 2. and because of that, no one else used version control for
| submitting changes, they just sent patches to lkml
|
| 3. there was some use of CVS for some ports / subsystems, but
| again, it was used to generate patches to email to linus
|
| 4. people built lots of tools around this work flow, like
| `patchwork` and horrible shell scripts
| ranting-moth wrote:
| Of course you can run your project like Linux. Your first
| requirement is to employ Linus Torvalds as a project manager.
| interroboink wrote:
| I liked the thorough article, but my goodness did they beat
| around the bush w/regard to _their_ actual contribution to this
| process (per the title).
|
| I think the short version is: they made `git-cinnabar`, which is
| a git-to-hg translator, to help git users interact with the
| Mozilla repos.
|
| ----
|
| One contribution I can make:
|
| > For reasons I don't know, Mozilla decided to use separate
| Mercurial repositories as "branches".
|
| Originally, separate clones was the recommended way to do "topic
| branches" in Mercurial (not to be confused with "named
| branches"). There was no direct equivalent to git's branches.
| Eventually, Mercurial got 'bookmarks' which basically closes that
| gap, but that only became a core feature in 2011, well after
| these Mozilla repos were established.
|
| ----
|
| Aside: I prefer Mercurial myself, and I hope to keep using it for
| personal projects until I die (:
| glandium wrote:
| Author here.
|
| > my goodness did they beat around the bush w/regard to their
| actual contribution to this process (per the title).
|
| Fair point. I came up with the title first. Then as the content
| grew large and diluted the essence of the title, I
| reconsidered, but ended up sticking to it as a shameless
| clickbait.
|
| > Originally, separate clones was the recommended way to do
| "topic branches" in Mercurial (not to be confused with "named
| branches").
|
| That still leaves the question "why topic branches rather than
| named branches?". For the needs of the rapid release process,
| named branches could have been used, but weren't. I haven't
| tried to contact the people involved at the time to have a
| definite answer. It's not /that/ important, and I'm not /that/
| curious.
| oktwtf wrote:
| My only experience with Mercurial was in game development. What's
| used these days in arenas where large file versioning is needed?
|
| I think the ultimate answer is maintaining an asset stack
| containing files that allow for inherit diff chunks or however
| that might be described.
| mjhay wrote:
| Reading that article unlocked some traumatic memories of
| Bazaar/"bzr".
| glandium wrote:
| Writing the article unlocked some traumatic memories of arch.
| hexo wrote:
| Thank you, mercurial was obstacle (for me) all the time. Thanks
| for killing it.
| sys_64738 wrote:
| Solaris source control moved to Mercurial so if you want to know
| if it scales then the answer is yes. I miss SCCS.
___________________________________________________________________
(page generated 2023-11-21 23:00 UTC)