- 17 Jun, 2021 4 commits
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Seen for the the first time in GitLab 13.12 context, as in the new test. Probably a call somewhere that doesn't bother to check for emptiness first.
-
-
- 16 Jun, 2021 1 commit
-
-
- 26 May, 2021 5 commits
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
mostly to make obvious it's been done and perhaps limiting the number of conflicts in .hgtags
-
Sushil Khanchi authored
-
- 25 Mar, 2021 2 commits
-
-
Sushil Khanchi authored
-
Sushil Khanchi authored
-
- 23 Mar, 2021 1 commit
-
-
Sushil Khanchi authored
-
- 25 May, 2021 1 commit
-
-
Georges Racinet authored
This demonstrates how to use `message.Logging`. It is still quite partial, but we can generalize later, and make logging of incoming requests more systematic.
-
- 04 Apr, 2021 1 commit
-
-
Georges Racinet authored
With gRPC, the `repr` of messages, notably Gitaly Requests is made of multiple lines. This is very bad for logging: a log should always be made of a single line for: - meaningful grepping - detangling when several processes log to the same file We want in particular service method to be able to log easily their incoming requests and/or more messages, but we want the formatting to be done only if the log is actually to be emitted (important to avoid debug logs to make production servers choke). This is usually achieved with the following pattern, because logging evaluation is inherently lazy. ```python logging.debug('the interesting object is %r', obj) ``` We could use extras, as `hg-loggingmod` does for the repository, but that is evaluated in the final formatting of the entire log line, and requires to register a specific format, then a specific handler to use it. The provided solution (wrapping in a class), is not zero-cost, but is expected to be cheap enough for the time being.
-
- 18 May, 2021 1 commit
-
-
Georges Racinet authored
This goes with the general preparation for Heptapod 0.22 and comes with interesting diff options.
-
- 25 Apr, 2021 2 commits
-
-
Georges Racinet authored
Now that everything is back to normal, it is mandatory again.
-
Georges Racinet authored
This was covered by Gitaly comparison tests, but not by direct tests. The resulting CI failure was masked by the temporary incompatibility of hg-evolve stable with Mercurial stable due to the latter being bumped to 5.8rc
-
- 24 Apr, 2021 1 commit
-
-
Georges Racinet authored
-
- 22 Apr, 2021 11 commits
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
Nothing of consequence to us: - more comments - removal of `name` field for Git remotes (mirrors-related) operations
-
- 11 Apr, 2021 5 commits
-
-
Sushil Khanchi authored
-
Sushil Khanchi authored
There was a case, found while writing gitaly comparison test for FindCommits (next patch) where current DAG logic missed some cset to include. r1...r2 revspec means, csets ancestor of r1 or r2, but not ancestor of both. Graph: D | \ B C | | | / A | O revspec: 'D...B' Expected revs: (D, C) Logic before this patch would return: (D,)
-
Sushil Khanchi authored
-
Sushil Khanchi authored
The change around offset make sure that we follow along with Gitaly and give priority to offset first, then limit. If no limit is passed, then request.limit is Zero.
-
Sushil Khanchi authored
-
- 21 Apr, 2021 2 commits
-
-
Georges Racinet authored
The reason why Gitaly does not respect `WRITE_BUFFER_SIZE` even though the Blob serving method go through its `streamio.SendWriter` object which enforces it is now roughly understood: the `SendWriter` object is called for the smaller chunks generated by `io.CopyN`. Since this does not look to be the actual intent in Gitaly and may be corrected later, we make HGitaly abide to `WRITE_BUFFER_SIZE` right away. This makes our code more consistent. Also, this makes the default chunk size go up from 16kB to 128kB. It wouldn't be very surprising if the penalty for chunks that are too small (number of requests multiplied by 8) would be bigger in a Python program than in a Go program, because we may have a higher overhead per request.
-
Georges Racinet authored
This fixes a flakiness in the comparison tests for `get_blob` and `get_blobs`: Gitaly's chunking is not constant, seems to depend on the (circumstantial) size of some inner buffers or similar. Hence a direct comparison of Gitaly and HGitaly responses is flay. Instead, we are focusing on what matters: repetition of metadata like oid and size (or not) and of course that the whole content is correct.
-
- 22 Apr, 2021 2 commits
-
-
Georges Racinet authored
(merged from stable branch)
-
Georges Racinet authored
It seems that the current stable branch of hg-evolve is not ready for the current stable branch of Mercurial (5.8rc)
-
- 15 Apr, 2021 1 commit
-
-
Georges Racinet authored
-