acda8b3725
The high-level API is simplified: we no longer ask callers to distinguish between insert/update/upsert, and instead use upsert everywhere, calling it "put". These distinctions were not particularly important from the perspective of e.g. the REST API. Although API simplification is a good thing regardless, this change was primarily driven by the fact that we do not want to use the eagerly-read ChangeNotes from within ChangeUpdate internals prior to actually applying the update. The various checkArgument calls in insert/update/upsert were trying to enforce, for example, that we only insert changes that don't exist at the time the setter was called. But in the context of NoteDbUpdateManager that executes multiple ChangeUpdates in sequence, it doesn't make sense to look up a comment in the old comment map based on the current branch tip when the ChangeUpdate instance was created. Instead we should be looking at the comment map that is the immediate output of the previous update in the sequence. This distinction is precisely what was causing the test in I064f004e to fail. To solve this problem at the storage layer, instead of depending on the NoteMap from the original ChangeNotes, read the RevisionNotes from the current revision passed in from the NoteDbUpdateManager (which may not have been flushed yet, but is still available to the reader). Don't bother reading the whole ChangeNotes again, as that is unnecessary. Encapsulate the RevisionNotes and the mutable NoteMap instance itself in a small POJO, RevisionNoteMap. In the common case of a single ChangeUpdate, we can even reuse the previously parsed RevisionNoteMap from the ChangeNotes that was passed in; we only have to re-read when doing multiple updates. Mutations are done to the RevisionNoteMap using the same RevisionNoteMapBuilder idiom we were already using for merging push certificates with inline comments. Moreover, we can use the same logic within ChangeDraftUpdate, obviating the need for DraftCommentNotesParser and simplifying the parse codepath somewhat. Finally, this change improves reliability and robustness around the fact that we are writing ref updates to two distinct repositories non-atomically, the change meta repo and All-Users. Order the updates so that the write to the change repo happens first, taking advantage of the fact that comments can only go from DRAFT to PUBLISHED, not vice versa. If the change update succeeds and the All-Users update fails, then we will have a zombie DRAFT comment left in All-Users where there is a PUBLISHED comment in the change repo. We fix this up in two ways: at read time, by explicitly filtering out any comments from the draft list that are also published; and at write time, by deleting all zombie draft comments any time we write any other draft comment. Add test cases for a few more combinations of comment updates, including one that simulates a failed All-Users write. Change-Id: I69c46ab4b55d4e40ad80754ee8528e99ae6ad4c5
Gerrit Code Review
Gerrit is a code review and project management tool for Git based projects.
Objective
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.
Documentation
For information about how to install and use Gerrit, refer to the documentation.
Source
Our canonical Git repository is located on googlesource.com. There is a mirror of the repository on Github.
Reporting bugs
Please report bugs on the issue tracker.
Contribute
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.
Getting in contact
The IRC channel on freenode is #gerrit. An archive is available at: echelog.com.
The Developer Mailing list is repo-discuss on Google Groups.
License
Gerrit is provided under the Apache License 2.0.
Build
Install Buck and run the following:
git clone --recursive https://gerrit.googlesource.com/gerrit
cd gerrit && buck build release
Install binary packages (Deb/Rpm)
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>]
NOTE: release is optional. Last released package of the version is installed if the release number is omitted.
Events
- March 14-18 2016: Gerrit Hackathon, Berlin (free seats are still available).