- User Since
- Jul 1 2017, 5:02 PM (54 w, 5 d)
Wed, Jul 18
Tue, Jul 17
CC @wlis since this change will impact Facebook. I'd also appreciate validation of my assertions in the commit message about the behavior of remotefilelog and working directory updates being more I/O than CPU/GIL bound.
Mon, Jul 16
I'm OK with this undocumented hack. And there are cases where we may want to test setup.py outside the context of a checkout as well. The important thing is end-users not running Mercurial with Python 3 unknowingly.
Fri, Jul 13
Wed, Jul 11
I don't understand phases code that well and am not sure if I'll be able to contribute a fix for the underlying issue in the next few days. If someone wants to take a shot at it, I could use the help.
Thu, Jul 5
Wed, Jul 4
Tue, Jul 3
Sun, Jul 1
Sat, Jun 30
Mon, Jun 25
Jun 18 2018
Jun 17 2018
Also, it's worth keeping in mind Python function call overhead when working on this code. I'm optimistic that things that need progress bars won't be concerned about this. But it might be worth measuring and keeping in the back of your head.
The low-level progress API has always bothered me as well.
Jun 16 2018
I'm getting a few test errors applying this against the latest revision of hg repo:
Overall I think this is a great feature! The patch as is needs a bit of UI work.
I think having better display of graph symbols is a compelling end-user feature and should be part of Mercurial.
I'm unsure about this change. On one hand, the comment (which appears to have been added to mpm several years ago) implies that we never should have generated backups in this case. On the other, one of the key rules of a VCS is "don't eat my data." Even though we are aborting the operation, I could see some scenarios where someone would want a backup of the aborted/partially-completed rebase.
I agree with @yuja that we should move this to util.py or one of its siblings and rename it to uninterruptable or some such.
So Python 3 is performing a lot more read(-1) calls than Python 2? That, uh, seems weird and might be worth investigating.
Jun 12 2018
Jun 7 2018
Jun 6 2018
May 30 2018
I think this is a cool idea! I could nitpick some of the glyph choices (e.g. U+233E ⌾ is really small and harder to read than @ and U+25CC ◌ looks like a circle and therefore the standard node type). But overall I like it!
I'm -0.25 on this.
I'm assuming https://abseil.io/ is part of the standard environment in oss-fuzz. Otherwise, we may want to vendor it or provide a script to download it or something.
I installed Dejavu Sans Mono from https://dejavu-fonts.github.io/ and it works great!
FWIW, this isn't rendering nicely with PuTTY on Windows 10. The U+25EF ◯ glyph is being truncated on the right side. I'm also seeing empty squares for U+233E ⌾ and other code points. Using Courier New as the terminal font. LANG=en_US.UTF-8 and TERM=xterm-256color, so Mercurial detects the encoding as UTF-8.
May 25 2018
I'm assuming we don't need to bump the state version since the new state file format is still relatively new. But if we had shipped the new state file in a release, I would insist on bumping the state version any time new data is added to state.
May 21 2018
This one worries me a bit because environment variable values can contain non-ASCII. However, the changed code only operates on HG_ variables and I think those variables are well-sanitized and should be ASCII safe.