| commit | 6cd9b6b04e82e779106b536329b9fb6465797ffe | [log] [tgz] |
|---|---|---|
| author | Saša Živkov <sasa.zivkov@sap.com> | Thu Oct 27 10:03:02 2022 +0200 |
| committer | Saša Živkov <sasa.zivkov@sap.com> | Tue Nov 08 16:11:58 2022 +0100 |
| tree | 81fd6451b84c3f9ff1688a6b153c9aa0f7f676da | |
| parent | e8489d16dd10779d7afbfc23a7378f9c601914c5 [diff] |
copy-approvals: multi-threaded, slice based This is similar approach like in the change reindexing. We split the work into slices of changes and then utilize one thread per slice. When approvals are copied for all changes in a slice we cannot perform BatchRefUpdate immediately. This is because multiple threads may try to perform BatchRefUpdate for different slice of the same project and this will create contention on the locking of the packed-refs. Therefore, we only prepare all the objects for the ref-updates and save the (pending) ReceiveCommands in a Map keyed by project. When all slices are processed we then create a new BatchRefUpdate, add all pending commands and execute one update per project. As a side effect of this implementation, we do not perform indexing of changes after approvals are copied. The indexing was anyway unnecessary as copy-approvals only changes how data is stored but doesn't change the data. By skipping reindexing we can dramatically improve the performance of the copy-approvals program. On a large Gerrit site with a 1.3 millions of changes, the combination of using thread per slice and skipping indexing reduced the time for the copy-approvals program from 5 hours down to 15-20 minutes. Forward-Compatible: checked Release-Notes: use multiple threads for copy-approvals, improve performance Change-Id: I493b9d7ee0d25b3ad9b741f5eaf3c6b86172a04c
Gerrit is a code review and project management tool for Git based projects.
Gerrit makes reviews easier by showing changes in a side-by-side display, and allowing inline comments to be added by any reviewer.
Gerrit simplifies Git based project maintainership by permitting any authorized user to submit changes to the master Git repository, rather than requiring all approved changes to be merged in by hand by the project maintainer.
For information about how to install and use Gerrit, refer to the documentation.
Our canonical Git repository is located on googlesource.com. There is a mirror of the repository on Github.
Please report bugs on the issue tracker.
Gerrit is the work of hundreds of contributors. We appreciate your help!
Please read the contribution guidelines.
Note that we do not accept Pull Requests via the Github mirror.
The Developer Mailing list is repo-discuss on Google Groups.
Gerrit is provided under the Apache License 2.0.
Install Bazel and run the following:
git clone --recurse-submodules https://gerrit.googlesource.com/gerrit
cd gerrit && bazel build release
The instruction how to configure GerritForge/BinTray repositories is here
On Debian/Ubuntu run:
apt-get update & apt-get install gerrit=<version>-<release>
NOTE: release is a counter that starts with 1 and indicates the number of packages that have been released with the same version of the software.
On CentOS/RedHat run:
yum clean all && yum install gerrit-<version>[-<release>]
On Fedora run:
dnf clean all && dnf install gerrit-<version>[-<release>]
Docker images of Gerrit are available on DockerHub
To run a CentOS 8 based Gerrit image:
docker run -p 8080:8080 gerritcodereview/gerrit[:version]-centos8
To run a Ubuntu 20.04 based Gerrit image:
docker run -p 8080:8080 gerritcodereview/gerrit[:version]-ubuntu20
NOTE: release is optional. Last released package of the version is installed if the release number is omitted.