durin42

I asked sometime in 2024 and I got a pretty clear response that local/self hosting is not planned.

That's how I look when I'm excited

I can confirm this (we've worked together)

Or listen to Daniel Berlin, who's both an accomplished GCC hacker and a lawyer:

https://news.ycombinator.com/item?id=9956542 https://news.ycombinator.com/item?id=13979443

This isn't settled law, and DannyBee would be quick to point out that the practice of law has a major component of risk management.

1) hg absorb

2) hg-git exists, and there's other things afoot that should be better

Please feel encouraged to report a bug about histedit slowness with some details so we can try and reproduce and consider a fix.

Piper still exists, but Mercurial is a viable client tool to interact with Piper's version history.

Sounds a lot like https://twitter.com/indygreg/status/1028097388261433344 - I'm pretty sure Greg was working with hg when he noticed this issue.

In any event, if you're enthusiastic about this kind of thing, we'd love to have more eyes on making hg checkouts consistently fast, even in the face of filesystems undermining those efforts. ;)

How long ago was this? And what OS? I know we're faster than unzip on some platforms, but IIRC we just found a pretty awful performance issue on...linux? I think?... that meant our parallelized approach to writing files was burning a ton of time in the kernel filesystem locks or something.

You might find https://github.com/jcs/bitwarden-ruby an interesting hosting alternative, FWIW.

rewrite a large part of hg in Rust

That's not really the right story. The motivating factor is that we'd like to write /less C/, not /less Python/. It's likely in the long-term that parts of the code that are performance sensitive will move out of Python, but we've been doing that for years, and we just keep finding new things to optimize as the scale of Mercurial repositories keeps increasing.

Last I knew it worked fine, but hg doesn't tend to run long enough for the JIT to warm up enough and be an unambiguous win. Fijal complemented us on how good our C was.

I think it does work if you do chg with a commandserver in pypy.

Go isn't really a huge win for hg, and it doesn't support being used as a shared library, so we couldn't easily use it as a replacement for C for native extensions. main() has to be in Go, and even then you've got two GCs in the mix which is not great.

There's pretty broad consensus that we'd like to do Rust and not C for future extension work, but the current plan is that a pure-Python hg will also be something we support. The "rust binary that embeds Python" approach looks like a straightforward win on Windows, where we have a native .exe that embeds Python anyway. I'm not sure if that'll make sense on non-Windows, but we'll see.

I've done some poking around with milksnake, which seems extremely promising for writing native speedups.

I wouldn't worry. It sounds very similar to what's been in Apache2 for years: http://en.swpat.org/wiki/Patent_clauses_in_software_licences...

All the communities I know that are centered around diff-in-email patch review are quite frustrated by the available GUI tools (most of them are only good for one patch at a time, or treat an entire stack of patches as one change). If you get somewhere with this, let me know? We might be interested in testing it on Mercurial depending on how it integrates with the email side...

That's actually pretty comparable to how we tend to operate the Mercurial project, FYI. We tend to prefer rebase to merge for feature work.

Sprints are twice a year, once in the US and once in Europe.

That's pretty standard as the assumed interest rate for investing in index funds over a long period.

It's likely that Mercurial would scale for you today, using Facebook's stack. Drop me an email if you'd like to chat sometime.

It's not a fork - they've got some extensions for some special things, yes, but they're running mostly stock Mercurial.

Some game shops have had good luck with Mercurial's largefiles extension, for what it's worth.

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. :)

Nope. mpm has been wanting to move on for a while, it's only recently that he's published plans more publicly.

I mentioned this over on lobste.rs, but I'll mention it here in brief: fair.io does a really bad job of stating this intent. The elevator pitch mentions open source but not proprietary. Please consider rewording fair.io to be clearer about the non-open-source intent here.

I was excited by this project until I saw the license, and then I decided to not touch it at all until lawyers look at the license.

So, a question that immediately arose for me out of reading that license: what's the definition of a user? If I wanted to use this to self-host my own projects, is everyone on the internet a user? Am I limited to 15 collaborators on my project unless I pony up? Is that 15 collaborators over all of time, or within some time interval?

The owners manual for the VW TDIs actually warns you to not try and preheat the engine by letting it idle in the winter, because it won't work.

For what it's worth, Chevy is selling a diesel version of the Cruze in the US, and it has better performance numbers pretty much all around than the VW. I'm skeptical of the claims that this is "the end of clean diesel" as a result.

Note that the pump in question has been redesigned multiple times by Bosch. Hardware bugs are a thing, even in cars.

Cars built since MY 1996 are self-diagnosing for most emissions problems. Mandating factory-original parts simply means the auto manufacturers won a major political battle, not that anything effective is being done.