- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Tue, May 24
Tue, May 17
I'll remove a hardlink=True comment (which is not really worthy of a phabsend), but I don't understand the purpose of the split between (1) and (2). The only reason we're removing a directory is that we're creating it and putting temp files there.
Actually, a commit message could be improved...
Tue, May 10
Mon, May 9
Thu, May 5
Wed, May 4
Apr 22 2022
Apr 21 2022
ZFS bug and lack of tests notwithstanding, the change seems good to me.
Relevant issue: https://github.com/prometheus/prometheus/issues/484.
Presumably hg has reasonable expectations here, the bug is in ZFS. However this does mean that we in Jane Street will experience issues since we don't seem to have a patched ZFS.
This also means that this code path is untested, yes? (Since I'm not seeing any errors) Do you know how to reproduce the append behavior so we have a test that breaks on buggy ZFS?
Wow, this is actually different on different filesystems: the behavior I described happens on ZFS, while a presumably-desirable behavior (different offset every time) happens on EXT4 and XFS. This is crazy!
Yep, same in rust:
Ok, I get it. You're saying size 0 is special because a write of size 0 does not update the current file pointer.
I did not know exactly how append mode interacted with lseek, so I did an experiment.
The following C program always prints "hi2" for me, even if redirected to a file in append mode.
I think this means that even though write in append mode always appends to the end of the file, it doesn't actually advance the file pointer to that position, so the returned value is effectively the amount you wrote, not the total size of the file.
(I did not try the same in rust)
I don't understand the justification: if it's not correct to store the file length when we're appending empty data, why is it correct to store it when data is not empty? Can't the garbage still be there?
Apr 20 2022
In D12542#192640, @Alphare wrote:FYI both this and D12543 had to be amended because they failed to pass the formatting tests
Apr 19 2022
Apr 14 2022
In D12549#192062, @Alphare wrote:Thanks for adding this test. Do you have a fix coming?
Apr 13 2022
Apr 12 2022
Mar 2 2022
Feb 22 2022
That's cool. Thanks.
Feb 21 2022
There is no benefit to fast-pathing the mismatch case, so it's better to keep the code simple.
In particular the code being removed is hard-coding the fact that the default value is abort, which is something we want to change in the hg deployment we use.
Removing this fast-path make configitems.py the only place where the default value is specified.
Feb 18 2022
Feb 17 2022
The condition to skip just the ENOENT errors is equivalent to the one in osutil.c (line 393). Unfortunately, I believe the pure code is still buggy: there's still the same bug at mercurial/pure/osutil.py line 62.
This is a bug that leads to hg status wrongly saying that the whole directory is deleted even though only some of the files in it was deleted (potentially one of the ignored files, in which case the status could even be clean).
I tested it using the following command:
Jan 20 2022
This demonstrates a bug that results in a repo corruption any time a transaction is aborted that adds multiple revs of the same revlog while growing it beyond 128KiB.
I would have thought this affects most hg users, since none of the pre-conditions for this bug is very unique.
Probably this went unnoticed for such a long time simply because transactions are rarely aborted.
Dec 17 2021
Dec 13 2021
Thanks for your review!
The point is to make the output smaller.
Seems ok to output the whole file, too (pushed). (it was 50 lines, not 20, when I introduced it)
Dec 10 2021
The shell strikes again. :-\
I removed the problematic test, so it should be good now.
I don't know about revlog-v1 (it seems there are tests in the tree that are revlog-v1-specific and don't gate against it), but (the lack of) zstd compression is also changing the result, so clearly needs to be guarded against, since it's breaking the --pure build.
I pushed that change. If you have ideas how to make the test less fragile, those would be appreciated. One possibility is to remove the test of corrupted repo altogether, if you think that's better.
In D11882#182409, @Alphare wrote:...
The last test is a bit fragile, we should gate it for revlog-v1 only.
While working on comments I discovered that the rust implementation was different from the C/Python implementation in how it deals with a wrong value of delta chain base.
I made sure that rust code behaves the same as hg there (which is: ignore the corruption) and added a test that checks that.
Dec 8 2021
The last update was to fix the issue with --pure: the output of debugdeltachain was different there.