REVIEW ARTICLE MULTIVARIATE EXPLORATORY DATA ANALYSIS AND GRAPHICS:A TUTORIAL--《Journal of Geographical Sciences》1993年05期
REVIEW ARTICLE MULTIVARIATE EXPLORATORY DATA ANALYSIS AND GRAPHICS:A TUTORIAL
【摘要】：正 Exploratory data analysis(EDA)is a toolbox of data manipulation methods for looking at data to seewhat they seem to say,i.e.one tries to let the data speak for themselves.In this way there is hope thatthe data will lead to indications about'models'of relationships not expected a priori.In this res
【关键词】：
【正文快照】：
1 .INTRODUCTION1 .1.Aims of exPloratory data analysisJ .w.Tukey cl幻med that his fundamental work石!切toraro理Dara注nalysis’15 based on thePrineiPle that‘it 15 imPortant to understand what you can do before you learn to measure howwe刀you seem to have
欢迎：、、)
支持CAJ、PDF文件格式，仅支持PDF格式
【相似文献】
中国期刊全文数据库
杨(钅监);;[J];史学史研究;1980年01期
朱家溍;;[J];中国道教;1980年02期
欧阳中石;[J];中国戏剧;1981年02期
刘粤基;;[J];当代戏剧;1981年03期
黄裳;;[J];社会科学战线;1982年04期
栾开翔;[J];日本医学介绍;1985年03期
骆抗先;何超;沈淑华;潘南胜;林汝洪;乔世忠;;[J];Journal of Medical Colleges of PLA;1986年01期
邵胜定;;[J];图书馆杂志;1986年04期
;[J];集成电路应用;1986年01期
;[J];晋图学刊;1990年03期
中国重要会议论文全文数据库
罗崧发;余鸣风;许国生;;[A];第二届空间结构学术交流会论文集（第一卷）[C];1984年
Syed Hyder AS.Mughis AAhmad Umar S;[A];第二届国际非木材纤维制浆造纸会议论文集（一）[C];1992年
;[A];Selected Works of Geotechnical Engineering----Special Volume in Commemoration of the Golden Jubilee of ISSMFE[C];1983年
李秋红;周桃生;徐玲芳;马海峰;;[A];湖北省物理学会、武汉物理学会成立70周年庆典暨2002年学术年会论文集[C];2002年
赵宁渌;;[A];“安财杯”流通现代化研讨会论文集[C];2002年
Takatsune NShin SHiroshi WTomiichi H;[A];Proceedings of the 4th Pacific Rim Conference on Rheology[C];2005年
D.DG.J?;[A];Optical Test and Measurement Technology and Equipment(Part One)--Proceedings of the 2nd International Symposium on Advanced Optical Manufacturing and Testing Technologies[C];2005年
张肇西;;[A];QCD和RHIC物理国际学术研讨会论文集（Ⅱ）[C];2005年
;[A];Proceedings of the Eighth International Conference on Electrical Machines and Systems(Volume Ⅰ)[C];2005年
Yves M. HENON;;[A];食品与医疗卫生用品辐照标准和质量控制国家培训班暨学术研讨会文集[C];2006年
中国重要报纸全文数据库
通讯员　邓和平　　记者　王绍雄;[N];光明日报;2002年
张雪;[N];江西日报;2002年
徐大成;[N];中国艺术报;2004年
薄一波;[N];人民日报;2004年
龚育之;[N];文汇报;2004年
龚育之;[N];学习时报;2004年
龚育之;[N];学习时报;2004年
傅长盛 通讯员
华平;[N];闽西日报;2008年
&快捷付款方式
&订购知网充值卡
400-819-9993
《中国学术期刊（光盘版）》电子杂志社有限公司
同方知网数字出版技术股份有限公司
地址：北京清华大学 84-48信箱 知识超市公司
出版物经营许可证 新出发京批字第直0595号
订购热线：400-819-82499
服务热线：010--
在线咨询：
传真：010-
京公网安备74号Gerrit code review - Tutorial
Gerrit code review - Tutorial
Lars Vogel
Version 2.5
Gerrit tutorial
This tutorial explains the usage of the Gerrit code review
system. It describes the setup of Eclipse (with EGit) as well as the
command line setup. Contributing to an Eclipse.org project via Gerrit is also described.
Table of Contents
1.&Code review
1.1.&The code review process
During a code review process a proposed change
is reviewed by
other developers. Every contributor can
changes and update the
suggested changes. Once the change is
by a committer,
merged into the code base.
For an efficient process it is important that the code review is
conducted in a supportive environment where constructive feedback
given to enhance the change.
While a code review process can be implemented without any tool
support, it is typically more efficient if a structured code review
system is used. Gerrit is a code review system developed for the Git
version control system.
It is also common practice to do an automated test build of the
proposed merge
using continuous integration tools like Jenkins or
Hudson to check
for compile time errors and to run a test suite.
1.2.&Advantages of code review
In general a structured code review process has the following
advantages:
Early error detection:
Build problems are detected
immediately
by automatic test
flaws can be spotted by the human reviewer
before any code
Conformation to the source code standards:
Allows the
to identify early in the process any
violations with
the team code
standards.
Helps to keep code
readable and easier
In some projects the continuous integration system also
checks for code
standard conformity automatically as part of the
build process.
Knowledge exchange:
The code review process allows newcomers
to see the code
more experienced developers.
Developers get fast feedback on their
suggested changes.
Experienced developers can help to evaluate the impact
the whole code.
Shared code ownership: by reviewing code of other developers
the whole team gets a solid knowledge of the complete code base.
Easy entry to contribution: People
without write
permission to
a repository have an easy way to start contributing and to get
Enables review before a change is submitted: Iteration based
on review comments / build results happen before a change is
merged into
the target branch. This result in a cleaner history of
the repository.
2.&The Gerrit code review system
2.1.&What is Gerrit?
Gerrit is a web based code review system, facilitating online
code reviews for projects using the Git version control system.
Gerrit is a Git server which adds a fine grained access control
system and workflow.
The code review system is web based, facilitating online
for projects using the Git version control system. The
of Gerrit is based on
Google Web Toolkit
and its Git
implementation is JGit.
A developer can use Gerrit to suggest a change. Other
developers
can review the change and suggest improvements. If a
Gerrit change
needs improvement, it is possible to update it
with a new commit. Once
the suggested
changes are accepted by
reviewers,
can be merged to
the target branch in the Git
repository via Gerrit.
Gerrit makes code reviews easier by showing changes in a
side-by-side
display. It also supports to display the change as a
unified diff which is often
easier to read on smaller screens.
A reviewer can add comments to
every single line
Development takes place at
Gerrit is licensed under the Apache license.
2.2.&Change
The Gerrit review system calls a code review / review request
change. Each change is based on one commit.
2.3.&How does Gerrit work?
Gerrit can
users from pushing directly to the Git repository.
Gerrit, you use a certain path (ref specification) which tells
that you want to create a change. This push ref
specification is
refs/for/master
if the target of the change under review is the master branch. You
can also push to
refs/for/xyz
to put a commit into the review queue
for the xyz branch.
If you push to this ref specification, Gerrit creates a new change
makes an update of an existing one.
Gerrit uses the
information in the commit message to identify if the push is a new
commit or an update of an existing change.
A change consists of one or more patch sets which are used to
improve the first proposal based on review comments. One patch set
corresponds to one Git commit.
It is still possible to bypass code review by pushing directly to
refs/heads/master
if sufficient rights have been
2.4.&Review categories - Verified and Code-Review
Gerrit supports different categories (also known as labels) for
review feedback. In
default configuration it supports the
Code-Review
In typical installations also the
category is installed. See
"Verified"
category typically means you
able to build and
introduced with the Gerrit change.
Typically, this is
automated process such as a Jenkins / Hudson
build server.
The "Code-Review" category is typically used to
vote on the
quality of the implementation, code style,
conformity
and that the
overall design of
the code is
desired by the
Committers and contributors can vote in these categories.
2.5.&Voting in Gerrit
The rules for voting in Gerrit is:
Highest vote (+2 in Code-Review and +1 in Verified) enables
submitting
Lowest vote (-2 in Code-Review) is a veto blocking that the
change can be submitted and
can't be overruled by other reviewers
You cannot submit the changes to the Git repository until
there is the highest vote in all
categories
Typically Gerrit instances uses the
Code-Review
If you did
testing and the code works as you
desire then
in the "Verified" category, or
-1 if it failed some of
cases that must be
to merge. Otherwise, leave
if you did not test
Non-committers
of the project can
vote with -1 and +1
Code-Review to
indicate an
opinion in either
ultimately it is up
decision of those
with +2 power to
the overall decision. You
want to -2 vote to
submission
the code if it is not up to
par with your
standards or
to indicate that you approve
contribution is
Git repository.
2.6.&Gerrit online documentation
You find a quick introduction about
Gerrit at:
and detailed information in the
Eclipse specific information can be found on the
2.7.&Posting draft reviews
There is also a special
refs/drafts/master
refspec which you can
use to push changes to for private review before
publishing them to all developers.
This is useful if
your work is in
progress and not ready for
review. You can also
CC specific
people to review this private change.
Once it is ready for
review there is a
to convert the draft into a
3.&Installation of Gerrit
3.1.&Download Gerrit
Download the latest Gerrit release from
. The download is a
file which you can directly add to your servlet container, for
example, a Jetty or Tomcat installation.
file also contains a Jetty web server and can be started directly for
testing or rapid deployment. The following description uses this approach.
3.2.&Setup of Gerrit
file into an empty directory.
Switch on the command line to the location of the directory to which
you extracted the
Install and start
Gerrit with
the following command.
java -jar gerrit*.war init -d review_site
The installation procedure allows you to configure your Gerrit
installation. The installation is done in the folder specified with
parameter, in this example "review_site".
The installation procedure asks a few question, pressing enter uses
the default value which is typically fine for a test installation. A
few of these options are discussed in the following table.
Table&1.&Gerrit setup options
Description
Location of Git repositories
Location of Git repositories, default is the
in the installation folder of your Gerrit installation.
Database server type
Gerrit supports several databases, by default it uses a
preconfigured H2 database.
Listen on port
Allows you to configure the port Gerrit is listening to,
Gerrit by default listens on
port 29418 for SSH access and on
port 8080 for web access. This can
be changed if the ports are
already used.
Authentication method
The easiest way of
configuring access to Gerrit is to use
OpenID Single Sign-on
which is the default setting. Use ? to see all available
settings for this option.
development_become_any_account
to enable general access to Gerrit. This is a nice setting for
testing. If started with this setting, you have a
link in the web interface which allows you to login and to create a
new account.
After a successful installation Gerrit starts automatically. You
can start and stop it again with the following commands on Linux
based systems.
~/gerrit/review_site/bin/gerrit.sh start
~/gerrit/review_site/bin/gerrit.sh stop
On Microsoft Windows based systems you need to invoke the
daemon directly. From a command shell switch to the folder
gerrit_site and
run the following command to start the server.
cd gerrit_site
java -jar bin/gerrit.war daemon -d
This starts Gerrit.
To stop it again, kill the running process using
If something goes wrong, look into the
logs folder.
The local Gerrit configuration is stored in the
./review_site/etc/
4.&Gerrit workflow
4.1.&A typical Gerrit workflow
The following describes a typical workflow of a developer who
uploads a Gerrit review and a reviewer.
The developer fetches or pulls in the latest changes from the
Git repository
The developer create a new local branch based on the
origin/master
branch. This step
optional but it is considered a good practice
independent branch
per change to avoid unnecessary
dependencies
between commits (Gerrit
The developer implements a change(new feature, bug fix,
documentation change) and create a commit in his local repository
these modifications.
The developer implements (if necessary) more changes and
amends the existing commit,
until he is
satisfied with the change.
Afterwards you perform the following steps.
Push the change to the Gerrit review system to the
refs/for/master
refspec to create a change for the master branch.
If you receive improvement suggestions, fetch the latest
changes and rebase your patch onto origin/master
Repeat the last three steps until the patch is finally accepted
and merged into the codebase (or until the change is completely
rejected). Finally you can delete your
local branch.
4.2.&Gerrit vs. Git workflow
In the Gerrit scenario amending a commit
is used to update
Gerrit change request. Using the amend operation on a published
commit is usually
discouraged in Git, in Gerrit it is the normal
4.3.&Gerrit vs. GitHub workflow
The Gerrit review system is based on the assumption that each commit
is reviewed separately, while
at GitHub, a complete
branch is reviewed
and merging with the pull request.
5.&User setup
5.1.&Create user
You require a valid Gerrit user to work with Gerrit.
In a Gerrit installation in which you are not the
administrator, you ask the administrator to create a user for you,
but in your test installation you create your own users.
Login to Gerrit via
first user to login automatically gets the administrator
5.2.&SSH setup
If you want to use SSH you have to upload your SSH key. If you prefer
to use HTTPS, skip this step and go to
From the user drop down menu select
and select
SSH Public Keys
to upload your public SSH key.
Based on your SSH key you are now able to exchange data with the
Gerrit server.
to assign a
to your user.
5.3.&HTTPS setup
You can also enter a password for HTTPS access.
6.&Activate new change screen
At the time of this writing you can activate a new change screen
in your setting. In Gerrit 2.9 which was released June 2014 the new
screen is the default. This change screen shows the Gerrit changes in
more condense form.
By the time you read this, the "new" change screen might
be the default.
Screenshots of the change screen in this book are based on
new change screen and might be slightly different in the system you
are using.
7.&Administrator: upload Git repository
This part is only relevant for the administrator. Create a new
repository called
gerrittest
via EGit or the Git command line.
Create a the new Git repository in Gerrit via the following
ssh -p 29418 &userid&@localhost gerrit create-project demo/gerrittest
Since version 2.6.1 you can also click
Projects → Create New Project
in the web interface.
The new project can be found in the Gerrit web interface under
Projects → List.
Select your project and
Access. For testing give push rights to all registered users, which is the
default after
a fresh installation. In a productive
environment you can
Gerrit to be more restrictive.
Especially the access right Push Merge Commit
for feature branches named refs/heads/*
is something only trusted and experienced committers should be allowed to do.
8.&Administrator: create example project
Also for testing create a new Java project called
com.vogella.gerrit.example
in Eclipse that gets stored in a local
Git repository. Add a few
classes to it.
The following pushes the changes directly to the Git repository
without a change in Gerrit. Administrators are allowed to do
Afterwards
push the local Git
repository
to Gerrit by selecting
Team → Remote → Push.
Enter the following URL ssh://&userid&@localhost:29418/demo/gerrittest.git
in the wizard and press the
On the next page, click the
Add All Branches Spec
button and on the last wizard page the
9.&Clone repository from Gerrit
In this exercise you act as a
developer who wants to upload a
Gerrit review. This requires that you have a valid Gerrit user on the
Gerrit system.
For this exercise it is assumed that you have not yet a local Git
repository Therefore, you need to clone the Git repository from the
Gerrit server.
Open a new workspace for this.
Git Repositories
and select that you want to clone an existing repository. Enter
the URL from the Git repository hosted at Gerrit, for example:
ssh://&user-id&@localhost:29418/demo/gerrittest.git
10.&Developer: Gerrit configuration for the Git repository
After you cloned the repository from Gerrit, right-click in the
Git Repositories
remote and select
Gerrit Configuration....
The default values in this dialog should be okay. Press the
This sets your push configuration for this remote to
refs/for/*
which tells Gerrit that you created or updated a change.
push configuration, right-click on your remote and select
Configure push
and ensure that the setting is similar to the
following screenshot. It
also adds a flag to your repository to tell the Eclipse Git tooling to
Gerrit Change-id.
Properties
on your repository to see the details of your repository
configuration.
refs/for/*
ensures that every push is handled by Gerrit. If you use the
refs/heads/master
ref mapping, you can directly push to the Git repository. This
is typically restricted to administrators.
You can also do this setup directly via the Git command line.
git config remote.origin.push refs/heads/*:refs/for/*
11.&Creating and updating a Gerrit change request from Eclipse
In the following description we make a change in our local
repository and create a Gerrit change request.
Create a new local branch starting from the origin/master branch.
Perform some changes in your Java project. Commit the changes and
ensure to select the
Add Change-Id
button in the
Git Staging
The Change-ID is what uniquely identifies the change in Gerrit.
entry is initially set to
Change-Id: I0000.
During the commit, this is replaced with an ID generated by the Git
Push the change. As you adjusted your push configuration, this
should create a change. The Eclipse Git tooling shows a dialog after
its push, which contains, if the push was successful a URL to the
review. Is also contains error messages in case the push was not
successful.
Via the URL you can access the Gerrit web
interface and
analyze the Gerrit review.
Do a few new changes to your Java project and commit them to your
local Git repository. Ensure that you amend the existing commit. This
makes sure the
change id is used and avoids that Gerrit cannot
apply your change
because of a dependency cycle on the commits. Push
your new commit
to Gerrit, this should update the existing review
request. The Eclipse Git push confirmation dialog should tell you that
you created a new change set.
12.&URL for reviews
To see the reviews on your Gerrit server, open the link to your Gerrit
instance. For
example if you have Gerrit locally installed use
http://localhost:8080/ which is the default port for a local Gerrit
installation.
Or if you want to see the Gerrit reviews for the Eclipse
all change requests, if you login into the Gerrit instance you
see Gerrit changes you are involved with.
13.&Using the Gerrit web interface
13.1.&Reviewing a change request
Click on one change request to see the
details of the Gerrit
change request. Click on the commit message of the file name
(highlighted in the
screenshot)
to see the changes in the file.
double-click on
a line to comment on the change.
Clicking on
Up to change
brings you back to the change.
Gerrit allows you to review the commit
message, which appears at
the top of the
list. To understand the history of the repository
it is important to provide a good commit message.
13.2.&Publishing your review result
to give feedback on the change.
You can give a summary of your feedback and return a review
number between -2 and +2 (if you are a committer) or between -1 and
+1 (if you are not a committer).
Only developers with write access to the repository
If you vote -1 or
-2, you indicate that the patch still
rework or that you
disagree with the suggested change. See
for details of the default voting rules.
13.3.&Improve a change based on review feedback
If the review process has resulted review comments explaining
improve the proposed patch, the author of the patch (or someone
can adjust the
patch. The developer
amends the
commit in his local
repository and
pushes the improved commit
to Gerrit. He can
message while amending the commit.
As the developer amends the commit, the same
is used and the
Gerrit review system identifies the change as update
of the existing change.
Git Staging
view allows amending the last commit by clicking the amend button
shown in the screenshot.
Gerrit allows you to select which patch sets you want to compare in
Comparison
view. Typically you compare the base version with the latest patch
set, but if e.g. you already reviewed patch set 3 you may want to
just see what the author changed between patchset 3 and patchset 5.
Once the change has reached the required quality, the
evaluation of the
Depending on the settings of the Gerrit repository, the Gerrit
review might have to be rebased. If you conflict happens during this
rebase operation you can trigger this rebase directly from the web
interface. If a change
is rebased, it
needs to be reviewed again.
Afterwards a developer with commit rights can submit the
This is typically done by the same committer who voted +2.
on the Gerrit configuration for the project, this
may only work
change is based on the
origin/master branch. Gerrit
allows the
committer and
contributor to
rebase the change if
that is not
13.4.&Keyboard shortcuts in Gerrit
Press the "?" key in the Gerrit web user interface to see the
actions you
can trigger via shortcuts. The available shortcuts depend
on there you are in the user interface.
The available shortcuts are different, depending on the page
13.5.&Fetching a change into a local Git repository
It is possible to fetch the changes from the Gerrit review into
another local Git
repository. The Gerrit page lists the
commands for
downloading the change. This is depicted in the following screenshot.
After fetching a change, the developer can adjust the change and
amend the commit.
If he pushes it to Gerrit, the change is updated.
should be coordinated by the author of the original
that two developers do the same work.
The Git tooling in Eclipse allows you to fetch a change from Gerrit.
For this, right-click on
the project
Team → Remote → Fetch from Gerrit.
When working with many projects, it is often easier to right-click
on the repository instead and access
Fetch from Gerrit
from there.
You can paste the change's number (shown in the change's
URL) and use
Ctrl+Space
to expand the change number to the list of patch sets, select the
one you want to download and fetch it into a new local branch.
Afterwards you can
to test the changes in isolation.
14.&Solving typical Gerrit problems
14.1.&You forgot to amend the commit
If you try to push a commit which contains the same ChangeId as
predecessor commit Gerrit will reject it and responds with the error
"squash commits first".
In this case you probably forgot to
amend the existing
commit but
the same Gerrit Change-ID. This is depicted in the following
In this case you need to squash the commits. This results in a
new commit which can be pushed to Gerrit. As you use the same
Change-ID this pushed commit will update the Gerrit review.
An easy solution to handle this is, to do a soft reset in Git to
previous commit and commit the change files again, this time with
the amend option. If you really intended to create two commits you
need to generate a new changeId in the second commit which was
The Git tooling in Eclipse allows squashing commits via the
Git Interactive Rebase
view. A simple way of doing this is by selecting the adjacent
commits you want to squash in the
view and by selecting
Modify → Squash
from the context menu.
14.2.&Handling merge conflicts
The submit step may fail due to merge conflicts, depending on
the Gerrit project configuration.
The easiest way to do so is via the
in the Gerrit web interface, if there are no conflicts.
resolve merge conflicts you have to do this locally
an updated commit. The
steps required to solve a merge
conflict are:
Rebase your local branch onto the latest state of
origin/master
Resolve all conflicts
Commit them using
Rebase → Continue.
Push your change again to Gerrit for review
This creates a new
patch set for the
change. The
set has to
pass the code review again.
Submit the new patch set change to
into the master branch.
14.3.&non-fast forward
You get this error message if you try to submit a commit in
Gerrit to the Git repository and the change would result in a
non-fast forward merge. The Gerrit service is sometimes configured
the setting to allow only fast-forward merges. The default submit
"Merge if necessary".
the pushed commit is not based on the current
branch, e.g., origin/master if you aim to merge your
change into this branch.. This problem is depicted in the following
The solution is to rebase your commit onto
origin/master. This updates your change onto changes which reached origin/master
while you were working on your change. Afterwards you push the commit
again to Gerrit.
for details.
15.&More infos on trouble shooting
15.1.&Remove a bad commit from a series of commits
If you create a series
of dependent commits, it might happen that
one of the commits
is rejected during the review
cannot merge the
other commits as they still
dependency to the
"bad" commit.
During the review process commit 2 are rejected.
The commit 3 and
commit 4 are still good and do not depend on the changes in commit 2.
The solution is to use interactive rebase to skip the bad
The Gerrit user interface does show "depends on" and "needed
by" fields
when it knows that a Gerrit review depends on another
review. This
manage your dependency trail.
15.2.&More error messages and their solution
for more error messages and their solutions.
16.&Gerrit integration into Eclipse
16.1.&Gerrit support in Eclipse
To use Gerrit in Eclipse, clone the repository as before and
your projects. By
default, the Eclipse Git tooling creates a
configuration that
pushes the
local master
branch to the remote master
branch. To connect with
Gerrit, change
the configuration to push the
local master to
refs/for/master
After cloning the repository you can configure Gerrit in the
Git repositories
by right-clicking on the
remote and selecting
Gerrit Configuration.
You can see the Gerrit review notes in Eclipse. Select
Commit Viewer
on a commit in the History View. In the Commit Viewer you have
additional tab called
Notes. Here you see the data which was created by
the Gerrit reviewer.
16.2.&Mylyn Gerrit
Mylyn provides an Gerrit connector for the Eclipse IDE.
To use it, install the
Mylyn Reviews Connector: Gerrit
from the Eclipse Juno update site. This plug-in allows you to create
queries for Gerrit changes.
17.&Contributing to Eclipse via Gerrit
This part of the tutorial has moved to
18.&About this website
18.1.&Donate to support free tutorials
Please consider a contribution
if this article helped you. It will help to maintain our content and our Open Source activities.
18.2.&Questions and discussion
Writing and updating these tutorials is a lot of work.
free community service was helpful,
you can support the cause by
as well as reporting typos and factual errors.
If you find errors in this tutorial, please notify me
Please note that due to the high volume of feedback I
receive, I
cannot answer questions to your implementation. Ensure you
I don't respond to questions already answered there.
18.3.&License for this tutorial and its code
This tutorial is Open Content under the
license. Source code in this tutorial is distributed under the
for details on the terms of reuse.
19.&Links and Literature
19.1.&vogella GmbH training and consulting support}