* Anyone can check-in to the Gerrit server. No role in the project is needed.
* The Continuous Integration server tests the commit before it is approved for commit.

* Anyone can check-in to the Gerrit server.
. No role in the project is needed. . The commits are eventually approved by someone with special rights in the
gerrit server and this causes a commit in the subversion repository in the Tigris project.* The Continuous Integration server tests the change before it is approved.

It has the following draw-backs:
* The testmodels are not available in the same place as they are when checking out with subversion. If building with maven, this is solved.
* You tigris id will not be the one doing the commit in subversion.

It has the following problems:
* You will work with git instead of subversion.
. If you have not used git before you need to learn the commands and
the principles.
. On the other hand, this is surely a benefit for those who prefer git.
* Your tigris id will not be the one doing the commit in subversion.
. Mitigate by writing your name in the commit message.
* The testmodels are not available in the same place as they are when checking out with subversion.
. If building with maven, this is solved by having the tests project
provided as a maven resource instead.
* The set of ignored files are not mirrored between git and subversion.
. This is a shortcoming in the git function that does the subversion
mirroring.
* The current Gerrit host is not backed-up.
. Mitigate by keeping your copy of the work (i.e. your git clone)
safe until your work is eventually committed into subversion.

Using GIT and Gerrit/Advocacy

This has the following benefits:

Anyone can check-in to the Gerrit server.

No role in the project is needed.

The commits are eventually approved by someone with special rights in the gerrit server and this causes a commit in the subversion repository in the Tigris project.

The Continuous Integration server tests the change before it is approved.

The Gerrit server can be used to discuss the commit before it is approved.

It has the following problems:

You will work with git instead of subversion.

If you have not used git before you need to learn the commands and the principles.

On the other hand, this is surely a benefit for those who prefer git.

Your tigris id will not be the one doing the commit in subversion.

Mitigate by writing your name in the commit message.

The testmodels are not available in the same place as they are when checking out with subversion.

If building with maven, this is solved by having the tests project provided as a maven resource instead.

The set of ignored files are not mirrored between git and subversion.

This is a shortcoming in the git function that does the subversion mirroring.

The current Gerrit host is not backed-up.

Mitigate by keeping your copy of the work (i.e. your git clone) safe until your work is eventually committed into subversion.