| commit | 15f648ac2f0ff1a8c840d5b9783e9764c9d2224d | [log] [tgz] |
|---|---|---|
| author | David Ostrovsky <david@ostrovsky.org> | Mon Sep 09 10:00:28 2019 +0200 |
| committer | Luca Milanesio <luca.milanesio@gmail.com> | Sat Jan 11 12:06:32 2020 +0000 |
| tree | 12d6d9b38c23a67ef718b6d83cfef51c49ffdcc5 | |
| parent | 97caed1d340e56fc52d8d049551835bb4faa2592 [diff] |
NoteDbMigrator: Totally skip migration for orphan changes This case was explicitly handled by ChangeRebuilderImpl, and NoteDbMigrator in fact caught RepositoryNotFoundException and let the migration proceed. Unfortunately, this would then cause the primary storage migration step to fail with: com.google.gwtorm.server.OrmRuntimeException: change X has no note_db_state; rebuild it first Work around this by catching this exception and checking after the fact whether the change is known to be unrecoverably corrupt. There is already another check in place: no patch set, in which case the migration process would also proceed, that was added in I0439c7fc8e5. So that we are just adding yet another "supported" kind of change corruption recovery mechanism to the migration proccess. Also add a test that is trying to migrate two different changes from two different projects, where one project was deleted on the file system. That test demonstrates, that one change is completely migrated while for another change the migration is skipped, as it is detected as corrupted change. The usual use case for orphan changes, also, the changes with not existing git repsitories on the file system, is often seen for gerrit test instances: Database replicated from the production system but only a couple of git repositories are replicated, leading to orphan changes. Reported-by: Alan Tokaev <tokaev@gmail.com> Bug: Issue 12097 Change-Id: I516f40f03feaafe3014fabb0c2f5c40d6753b8bc
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 7 based Gerrit image:
docker run -p 8080:8080 gerritforge/gerrit-centos7[:version]
To run a Ubuntu 15.04 based Gerrit image:
docker run -p 8080:8080 gerritforge/gerrit-ubuntu15.04[:version]
NOTE: release is optional. Last released package of the version is installed if the release number is omitted.