Merge changes Ib4cb4207,I64b967c9 * changes: Avoid opening the branch twice during submit Fix potential race in MergeOp caused by two reads
diff --git a/Documentation/dev-buck.txt b/Documentation/dev-buck.txt index 12b0f96..7671767 100644 --- a/Documentation/dev-buck.txt +++ b/Documentation/dev-buck.txt
@@ -306,67 +306,6 @@ EOF ---- - -Build Process Switch Exit Criteria ----------------------------------- - -The switch to Buck is an experimental process. Buck will become the -primary build for Gerrit only when the following conditions are met. - -1. Windows support. -+ -Facebook has an intern who will be working on this (summer 2013). - -2. Bootstrap and stable version support. -+ -From a fresh Gerrit clone on a machine without Buck (but with some -reasonable subset of Buck's dependencies, e.g. Python 2.7), a new -Gerrit developer should be able to set up and start building with -Buck by running approximately one command. There should also be some -idea of a "stable" version of Buck, even if we just tie our build -to specific known-good SHAs. Binary distributions are another plus, -which I believe the Buck team has planned. - -3. Shawn's Buck fork merged upstream. -+ -Shawn has a link:https://gerrit.googlesource.com/buck/+log/github-master..master[fork of Buck] -with some patches necessary to build Gerrit and run its unit tests. -These patches (or their equivalents) must be in the upstream Buck tree. - -4. Fix all incidental issues. -+ -Things come up that don't work. Martin just ran out of file -descriptors, which sounds like an upstream bug. -+ -There should be a consensus that new bugs like this in upstream -Buck are not constantly being introduced. - -5. Support development of custom plugins. -+ -There are three different alternatives for custom plugins: -+ -The first is to build with BUCK in tree; your plugin builds against -whatever version of Gerrit you have the sources checked out for. This -is the simplest method on master right now. The BUCK definition is -only a few lines of code and the rest "just works". But you are -working from a Gerrit source tree, which is maybe not the ideal way to -develop. -+ -Another is to continue to use Maven. We just have to package the -archetypes to support creating a new plugin, but existing plugins can -develop against the API JAR(s) if they are installed into a Maven -repository. tools/deploy_api.sh is how we did this for release -versions of Gerrit. Something similar probably still be used with BUCK -to publish the precompiled JARs. (Note: this is partially done with the -target: `buck build api_install`; after issuing this command the new API -version can be consumed by Maven driven custom plugins). -+ -The third option is to support a BUCK based plugin build outside of -the Gerrit tree. This is harder because there is functionality -developed as macros in the Gerrit tree that plugins would want to use -(e.g. gerrit_plugin rule). - - GERRIT ------ Part of link:index.html[Gerrit Code Review]
diff --git a/gerrit-server/src/main/java/com/google/gerrit/server/index/ChangeIndex.java b/gerrit-server/src/main/java/com/google/gerrit/server/index/ChangeIndex.java index f4a4f20..b67faa3 100644 --- a/gerrit-server/src/main/java/com/google/gerrit/server/index/ChangeIndex.java +++ b/gerrit-server/src/main/java/com/google/gerrit/server/index/ChangeIndex.java
@@ -89,8 +89,7 @@ * Results may not be immediately visible to searchers, but should be visible * within a reasonable amount of time. * - * @param cd change document with all index fields prepopulated; see - * {@link ChangeData#fillIndexFields}. + * @param cd change document * * @throws IOException if the change could not be inserted. */ @@ -103,8 +102,7 @@ * new field values. Results may not be immediately visible to searchers, but * should be visible within a reasonable amount of time. * - * @param cd change document with all index fields prepopulated; see - * {@link ChangeData#fillIndexFields}. + * @param cd change document * * @throws IOException */