4 ms·
Mercurial treats everything as bytes. Whatever you store in your repo, that's what Mercurial reads -- bytes. There are no encodings, there are no strings. Only
by jordigh 7y ago
Mercurial treats everything as bytes. Whatever you store in your repo, that's what Mercurial reads -- bytes. There are no encodings, there are no strings. Only bytes. You don't want your VCS to start having opinions about which language you should speak and how you should encode it.
PEP 461 was the bare minimum we needed before porting to Python 3 could happen:
http://legacy.python.org/dev/peps/pep-0461/ http://legacy.python.org/dev/peps/pep-0461/
We needed a way to put things into bytestrings.
And after that, it's just nothing but work. Lots of it. Little of which could be automated.
I get a little impatient, personally, with people who think that upgrading software is easy. We don't actually care about Python. We care about version control. Python is just some thing in the middle that is helping us produce version control. A multi-year effort to upgrade to Python 3 (or 3.8 or whatever) isn't giving us or our users a net benefit. In fact, until recently, it was a net loss, because Python 3.5 or 3.6 had slower warmup time, which is terrible for a tool like hg that needs to pay that cost every time you run any command.
Instead, Python 3 created busy work. Almost five years of it.
- armitron 7y agoMay I ask why you think it's worth doing all this work, especially now that Git has - clearly - won. How do you motivate yourself to keep working on mercurial and at what point do you cut your losses short? I assume you're not getting paid for it, so besides bragging rights or a nice CV entry, what else is there for you to look towards?
- jordigh 7y agoGit is horrible to use. Few people like it, most only tolerate it. Regardless of how you feel about git, there's plenty of literature regarding how awful the git user experience is. Mercurial's greater modularity also has made it easier to implement improvements for monorepos, although personally that's less important to me. That's why I still use and work on Mercurial.
- bipson 7y agoHighly subjective I would say. Git is not horrible to use. And even before I was a proficient Git user, mercurial was giving a team of 5 people a lot of work trying to fix stuff that just works on Git.
- bipson 7y agoAs much as I love Python, I get the feeling that you might have chosen the wrong language, or at least you used the wrong abstraction somewhere. Yes, I know that Python 2.x and 3.x handle bytes entirely different, yet I cannot understand how Python and their release planning should blindly "bend" to the demands of a project using the language. I understand you don't care about Python the least, but we do? We have to? I think that the maintainers simply had to move forward at some point, there has been a way too long grace period. And Python is not ANSI C. I think what you want of Python is to be never-ever-changing C89 and gcc still supporting it (I think it still does?)
- halfdan 7y agoI have no background on Mercurial but I'm curious whether it was considered to rewrite the entire thing from scratch in another language?
- jordigh 7y agoWe did. We rewrote it in Python 3. More seriously, there's also quite a bit of Rust now. https://www.mercurial-scm.org/wiki/OxidationPlan https://www.mercurial-scm.org/wiki/OxidationPlan