Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I kind of killed Mercurial at Mozilla

glandium.org

Post reply on HN
Print view View original

41–50 of 250 posts

Re: I kind of killed Mercurial at Mozilla

#41

Post by interroboink »

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 (:

Re: I kind of killed Mercurial at Mozilla

#42

Post by oktwtf »

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.

Re: I kind of killed Mercurial at Mozilla

#43

Post by petre »

fmajid wrote: post #17
wmf wrote: post #5

Earlier quoted context omitted.

FB/Meta replaced Mercurial with Sapling which is git-compatible: https://engineering.fb.com/2022/11/15/open-source/sapling-so... Mercurial is over.

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.

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.

Re: I kind of killed Mercurial at Mozilla

#44

Post by glandium »

CorrectHorseBat wrote: post #36

Linux kernel development never used cvs, I believe Linus thought it gives people brain damage and did just send around patches and tarballs

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

Re: I kind of killed Mercurial at Mozilla

#47

Post by AlotOfReading »

ge96 wrote: post #34
danking00 wrote: post #23

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.

bitbucket is worse, reviewees can resolve reviewer's comments (github has this too turns out), after file changes, comments disappear

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.

Re: I kind of killed Mercurial at Mozilla

#48

Post by aseipp »

1letterunixname wrote: post #12
wmf wrote: post #5

Earlier quoted context omitted.

FB/Meta replaced Mercurial with Sapling which is git-compatible: https://engineering.fb.com/2022/11/15/open-source/sapling-so... Mercurial is over.

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.

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.

Re: I kind of killed Mercurial at Mozilla

#49

Post by rbehrends »

petre wrote: post #43
fmajid wrote: post #17

Earlier quoted context omitted.

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.

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.

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

Re: I kind of killed Mercurial at Mozilla

#50

Post by zoogeny »

danking00 wrote: post #23

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.

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.

Post reply on HN