- Jul 09, 2019
-
-
durin42 authored
-
- Jul 08, 2019
-
-
Augie Fackler authored
Python 3 already does this, so skip it there. Consider the program: #include <stdio.h> int main() { FILE *f = fopen("narf", "w"); fprintf(f, "narf\n"); fclose(f); f = fopen("narf", "a"); printf("%ld\n", ftell(f)); fprintf(f, "troz\n"); printf("%ld\n", ftell(f)); return 0; } on macOS, FreeBSD, and Linux with glibc, this program prints 5 10 but on musl libc (Alpine Linux and probably others) this prints 0 10 By my reading of https://pubs.opengroup.org/onlinepubs/009695399/functions/fopen.html this is technically correct, specifically: > Opening a file with append mode (a as the first character in the > mode argument) shall cause all subsequent writes to the file to be > forced to the then current end-of-file, regardless of intervening > calls to fseek(). in other words, the file position doesn't really matter in append-mode files, and we can't depend on it being at all meaningful unless we perform a seek() before tell() after open(..., 'a'). Experimentally after a .write() we can do a .tell() and it'll always be reasonable, but I'm unclear from reading the specification if that's a smart thing to rely on. This matches what we do on Windows and what Python 3 does for free, so let's just be consistent. Thanks to Yuya for the idea.
-
- Jul 03, 2019
-
-
Anton Shestakov authored
-
Anton Shestakov authored
-
- Jul 02, 2019
-
-
Pierre-Yves David authored
If the file has no full snapshot (eg: was always empty), `hg debugrevlog` would fails when trying to compute their average size.
-
- Jun 30, 2019
-
-
Matt Harbison authored
This backs out 044045dce23a because it broke a bunch of tests on Windows. Yuya's theory is that we still rely on in-memory changelog data to be flushed out of the transaction.
-
- Jun 23, 2019
-
-
Matt Harbison authored
The help was output, but it was elided with "Enabled by default" from the previous item.
-
- Jun 21, 2019
-
-
Pierre-Yves David authored
This is a simple but efficient fix to prevent the issue tested in `test-bookmarks-corner-case.t`. It might be worth pursuing a more generic approach where filecache learn to depend on each other, but that would not be suitable for stable. The issue is complicated enough that I documented the race and its current solution as inline comment. See this comment for details on the fix.
-
Pierre-Yves David authored
See next changeset for usage and documentation for details.
-
- Jun 19, 2019
-
-
Pierre-Yves David authored
The previous committed version of the test did not triggered the race, but this was hidden by a strange behavior from the test runner. So we are moving the test to a slightly more complex that actually trigger the issue.
-
Pierre-Yves David authored
This cannot hurt to have a bit more security in the test extension.
-
Pierre-Yves David authored
The test is currently not testing the race it is supposed to test. The synchronisation is still valid, but needs to run at a different point. We start with extracting the synchronisation logic for clarity.
-
Pierre-Yves David authored
This code is the remain of a previous version of the code. It is never ran, so we can remove it.
-
Pierre-Yves David authored
Before this change, the following unified test input would silently pass $ echo foo foo (false !) After this change, the "foo" output is properly detected as unexpected. The output of an handful of test had to be updated from broken conditional (that ended up working by chance).
-
- Jun 16, 2019
-
-
Yuya Nishihara authored
Otherwise the template filter 'cbor' could crash because of bytes subclass: ValueError: do not know how to encode <class 'mercurial.encoding.safelocalstr'>
-
- Jun 01, 2019
-
-
Martin von Zweigbergk authored
I still don't quite know what the check does, but I clearly got it wrong in 526750cdd02d (bookmarks: keep bookmarks in .hg/store if new config set, 2019-05-15). Just compare with the strings we use in @repofilecache and @storecache. These bugs were then copied to the stable branch in c2b83c957621 (localrepo: grab mixedrepostorecache class from 526750cdd02d, 2019-05-20) and 2338bdea4474 (bookmark: also make bookmark cache depends of the changelog, 2019-05-20). As a result, test-wireproto-exchangev2.t is flaky on both branches. This patch fixes that. Differential Revision: https://phab.mercurial-scm.org/D6469
-
- Jun 05, 2019
- May 24, 2019
-
-
Matt Harbison authored
It was not particularly easy figuring out the design of this class and keeping track of how the pieces work. So might as well write some of it down for the next person.
-
Matt Harbison authored
Previously, removed files would simply be marked by overwriting the first byte with NUL and dropping their entry in `self.position`. But no effort was made to ignore them when compacting the dictionary into text form. This allowed them to slip into the manifest revision, since the code seems to be trying to minimize the string operations by copying as large a chunk as possible. As part of this, compact() walks the existing text based on entries in the `positions` list, and consumed everything up to the next position entry. This typically resulted in a ValueError complaining about unsorted manifest entries. Sometimes it seems that files do get dropped in large repos- it seems to correspond to there being a new entry that would take the same slot. A much more trivial problem is that if the only changes were removals, `_compact()` didn't even run because `__delitem__` doesn't add anything to `self.extradata`. Now there's an explicit variable to flag this, both to allow `_compact()` to run, and to avoid searching the manifest in cases where there are no removals. In practice, this behavior was mostly obscured by the check in fastdelta() which takes a different path that explicitly drops removed files if there are fewer than 1000 changes. However, timeless has a repo where after rebasing tens of commits, a totally different path[1] is taken that bypasses the change count check and hits this problem. [1] https://www.mercurial-scm.org/repo/hg/file/2338bdea4474/mercurial/manifest.py#l1511
-
Matt Harbison authored
This will be fixed next. But I don't fully understand how 'b.txt' is actually removed properly in the second test, given what's broken. Also, I'm not sure why 'bb.txt' is flagged as not being in the manifest, when it clearly appears to be.
-
- May 20, 2019
-
-
Pierre-Yves David authored
Since the changelog is also used during the parsing of bookmark data, it should be listed as a file cache dependency. This fix the race condition we just introduced a test for. This is a simple fix that might lead bookmark data to be invalidated more often than necessary. We could have more complicated code to deal with this race in a more "optimal" way. I feel it would be unsuitable for stable. In addition, the performance impact of this is probably minimal and I don't foresee the more advanced fix to actually be necessary.
-
Pierre-Yves David authored
On default, Martin von Zweigbergk <martinvonz@google.com> introduced a more advance filecache decorator. I need this decorator to fix a bug on stable. So I am grafting the relevant part of 526750cdd02d.
-
Pierre-Yves David authored
Bookmark pointing to unknown nodes are ignored. Later these ignored bookmarks are dropped when writing the file back on disk. On paper, this behavior should be fine, but with the current implementation, it can lead to unexpected bookmark deletions. In theory, to make sure writer as a consistent view, taking the lock also invalidate bookmark data we already loaded into memory. However this invalidation is incomplete. The data are stored in a `filecache` that preserve them if the bookmark related file are untouched. In practice, the bookmark data in memory also depends of the changelog content, because of the step checking if the bookmarks refers to a node known to the changelog. So if the bookmark data were loaded from an up to date bookmark file but filtered with an outdated changelog file this go undetected. This condition is fairly specific, but can occurs very often in practice. We introduce a test recreating the situation. The test comes in an independant changeset to show it actually reproduce the situation. The fix will come soon after. A large share of the initial investigation of this race condition was made by Valentin Gatien-Baron <valentin.gatienbaron@gmail.com>.
-
Pierre-Yves David authored
This part of the test can't run if zstd is not available. This was caught by --pure test (who don't support zstd).
-
Pierre-Yves David authored
In 1fac9b931d46 as new test session was introduced. It did not take in account some part that only ran for pure. The test is now fixed.
-
- May 08, 2019
-
-
Augie Fackler authored
By inspection, this is the only codepath that could be returning a string instead of a bytes on Python 3.
-
- May 07, 2019
-
-
Matt Harbison authored
-
- May 03, 2019
-
-
Yuya Nishihara authored
A tree node can be either None or a tuple because x=("group", None) is reduced to x[1].
-
- May 01, 2019
- Apr 25, 2019
-
-
Pierre-Yves David authored
Without this change, 5.0rc0 is not recognised as 5.0
-
- Apr 17, 2019
-
-
Pulkit Goyal authored
Before this patch, when ACL is involved, narrowspecs are send as bundle2 parameter for narrow:spec bundle2 part. The limitation of bundle2 parts are they cannot send data larger than 255 bytes. Includes and excludes in narrow are not limited by size and they can grow over 255 bytes. This patch introduces a new mandatory bundle2 part and send narrowspecs as data of that. The new bundle2 part is introduced to keep things cleaner and easy to distinguish related to backward compatibility. The part is mandatory because without server's narrowspec, the local ACL narrow repo won't work. This patch makes clients compatible with servers which have older versions. However I left a comment that we should drop the other bundle2 part soon as that's broken and people should not rely on that. I named the new bundle2 part 'Narrow:responsespec' because: 1) Capital 'N' to make it mandatory 2) 'Narrow:spec' cannot be used because bundle2 enforces that there should not be two different parts which resolve to same name when lowercased. 3) reponsespec clears that they are specs which are send as reponse by the server While I was here, I renamed `narrowhgacl` section to `narrowacl` as suggested by idlsoft@ and martinvonz@. Differential Revision: https://phab.mercurial-scm.org/D6310
-
- Apr 27, 2019
-
-
Matt Harbison authored
The error seems to be harmless, because it happens after closing the connection. For whatever reason, this isn't bundled with the Wix installer. https://github.com/jaraco/keyring/issues/386 https://bitbucket.org/Mekk/mercurial_keyring/issues/63/attributeerror-during-process-finish-with
-
- Apr 24, 2019
-
-
Pulkit Goyal authored
overlayworkingctx class is used to do in-memory merging. The data() function of that class has logic to look for data() in the wrappedctx if the file data in cache is empty and if the file is dirty. This assumes that if a file is dirty and cache has empty data for it, it will exists in the _wrappedctx. However this assumption can be False in case when we are merging a file which is empty in destination. In these cases, the backup file 'foo.orig' created by our internal merge algorithms will be empty, however it won't be present in _wrappedctx. This case will lead us to error like the one this patch is fixing. Let's only fallback to getting data from wrappedctx if cache has 'None' as data. Differential Revision: https://phab.mercurial-scm.org/D6308
-
Pulkit Goyal authored
When we are doing in-memory merging, and we are merging a file which is empty in merge destination, it leads to error 'abort: xxx not found in manifest'. Next patch will fix this error. Differential Revision: https://phab.mercurial-scm.org/D6307
-
- Apr 19, 2019
-
-
muxator authored
When building rpm packages for centos 5 and 6, we bundle a mercurial-specific version of Python 2.7 in /opt/python-hg. This change is analogous to 5e947367606c, and bumps the embedded Python version from 2.7.14 (released in 2017) to 2.7.16 (latest as of today).
-
- Apr 21, 2019
-
-
Gregory Szorc authored
We now have beta support for Python 3. In my opinion, it isn't yet stable enough to allow `pip install Mercurial` to work with Python 3 out of the box: we don't want people accidentally using Mercurial with Python 3 just yet. But I do think we should be more friendly about informing people of their options. This commit tweaks the error message that users see when running setup.py with Python 3. We instruct them about the current level of Python 3 support, point them at the wiki for more info, and give them instructions on how to bypass the check. As part of this, I also changed which version value is printed, as we were printing a named tuple before.
-
Gregory Szorc authored
Yuya observed in a recent review that it is worthwhile to keep setup.py parseable with Python 2.6 so a useful error message is seen when attempting to run with Python 2.6. This commit removes a set and dict comprehension so setup.py is parseable with Python 2.6.
-
- Apr 19, 2019
-
-
Pulkit Goyal authored
nodes are verified either when they are added or used. In case of commits. we will load the whole branchmap, only verify nodes for the branch on which we are committing and then we write. However before this patch, writing the branchmap was validating all the nodes whereas it should not. This patch fixes that. Differential Revision: https://phab.mercurial-scm.org/D6290
-