- User Since
- Aug 5 2018, 11:42 AM (156 w, 2 d)
I have been assuming that changes can still be submitted during a change freeze, but they are just going to get ignored for a few days. None of my changes are particularly intended to go on 5.9.
Sun, Aug 1
Sun, Jul 25
May 23 2021
May 21 2021
Maybe the forward slashes in the extension created at the beginning of the test is the source of the other windows failures?
May 20 2021
May 18 2021
Also, can you put (issue6423) in the first line of the commit message, so the bugzilla magic closes the issue?
Does the order of the truncates actually not matter, for concurrent readers? I don't really see how it could matter (linkrevs should make it possible to ignore everything not committed), but before looking at the rollback code, I imagined it truncated in reverse order of writes (and looking it up, it's what's described in the initial revlog paper).
I knew zstd could be turned off, but I didn't knew there was an option to turn off even zlib. Cool.
May 16 2021
Apr 11 2021
Apr 8 2021
Apr 6 2021
Mar 31 2021
Mar 10 2021
Mar 9 2021
Mar 8 2021
Feb 25 2021
Feb 15 2021
I submitted changes to close peers explicitly instead of doing this. It's definitely more invasive though.
Feb 14 2021
I made the command trivially compatible with py2, by keeping both implementations around. It seems ok, under the assumption that the the py2 has a limited lifetime (until py2 support is dropped), and that it doesn't affect the windows code path (so it affects OSes that should only be using py3).
Feb 9 2021
No particular opinion, I have not really followed this namespace discussion. I would have thought there's a number of other debugcommands that are admin commands, like debugrebuilddirstate, so one more wouldn't make a difference, but maybe that's incorrect.
Jan 25 2021
Closing the peer is what I was describing as solution 3 in D9019. But I think I was wrong in saying that it doesn't help with calls to logtoprocess in the middle of commands. I also just noticed that pull does that, in fact. I'll try and find some time to do that.
What's holding this back is lack of py2 compatibility. Although maybe I want to wait it out at this point. Do we expect to drop py2 in a few days, after 5.7 is released for instance?
Jan 22 2021
Nov 25 2020
Oops, sorry, I didn't have black installed, so test-check-format.t was getting skipped. Having installed it now (at version 19.10, because 20.8b is broken), there are indeed formatting issues. Thanks for the fix.
Nov 19 2020
Nov 18 2020
Nov 12 2020
Failing is what the vast majority of commands do when not given enough arguments:
$ hg clone hg clone: invalid arguments ... $ hg backout abort: please specify a revision to backout $ hg tag hg tag: invalid arguments ... $ hg resolve abort: no action specified ... $ hg revert abort: no files or directories specified ...
Raphael should probably chime in, but as a data point, for us, all installations use rust. And they will have to, when we enable persistent-nodemap soon.
The likelihood of bug and performance bugs is probably higher than without rust, for conditions not covered by tests. That being said, I remember only two bugs from the past 6 months, and they were fairly obscure (type error on linux on filesystems that don't respect exec bits, occasional spurious failure in hg clean when it races on the filesystem with something).
Nov 8 2020
I rebased, but there's nothing new here (apart from conflict resolution).
The discussion for py2 support was not super conclusive. But even given that D7258 uses py3 by default except on windows, and the fact the code changed here doesn't run on windows, I think I still need to make this change work with py2, so py2 issues from windows users can still be investigated from linux.
@joerg.sonnenberger are you stating what was discussed at the sprint merely for comparison, or because you'd prefer for this change to be closer to it?
Was that the conclusion? I think I was taking notes and missed it. I thought turning the strip extension into a debugstrip command was already agreed upon a year ago, In fact, D6987 was started back then (and stalled, but that's unrelated).
There's no disagreement that the command is dangerous, that's why it's debugstrip and not strip. That seems like better pushback to me than an extension.
Oct 15 2020
Ok. When I sent this, I thought the py3 switch was further along than it seems to be. I should be able to make this work on py2 (although I think it would merely reduce the chance of deadlock on py2).