Managing Repositories¶

General Information¶

• Name (required)

  This is the human-readable name of the repository that users will see. The name can be whatever you like and will appear on the “New Review Request” page and in the review request’s displayed information.

• Show this repository (optional)

  Determines whether or not the repository will be show. If this is unchecked, then users won’t see the repository in Review Board or through third-party applications that talk to Review Board.

  This is most often used for hiding a repository that’s no longer in use.

Repository Hosting¶

This is a complete list of fields that can be shown in this section. Not all of them will actually be shown at once. The fields will depend on the selected Hosting service and Repository type.

• Hosting service (required)

  The source code hosting service this repository will use, if any. This will be one of the following:

  • Bitbucket - The Bitbucket Mercurial hosting service.
  • GitHub - A public account at GitHub.
  • GitHub (Private) - A private account at GitHub.
  • Google Code - An open source Subversion or Mercurial project at Google Code.
  • SourceForge - An open source project on SourceForge.
  • Custom - A custom-hosted repository. This should be used if one of the above isn’t appropriate.

  See Hosting Services for more information.

• Repository type (required)

  This is the type of the repository. This will depend on the Hosting service selected.

• Project’s owner (required)

  The user that owns the project on the hosting service. This is used for hosting services that closely associate a project with an owner.

  This is only shown for Bitbucket and GitHub.

• Project’s name (required)

  The name of the project on the hosting service. This is different from the repository’s name.

  This is only shown when Hosting service is not set to Custom.

• API token (required)

  The API token provided by the hosting service. This is needed in order to access files on the repository. You will need to look at your account settings on the hosting service to determine the proper API token to use.

  This is only shown when Hosting service is not set to GitHub (Private).

• Path (required)

  This is the path to the repository on the server. It must be accessible by the server running Review Board. The value depends on the repository type. See Determining Repository Information below for more information.

  This is only shown when Hosting service is set to Custom.

• Mirror Path (optional)

  This is an alternate path for the repository that is used during lookups. It’s usually used when there’s separate developer and anonymous URLs for the repository, with the anonymous URL entered in Path and the developer URL entered in Mirror Path. Review Board will always use the main path when looking up files.

  This is only shown when Hosting service is set to Custom.

  See Determining Repository Information below for more information on the URLs.

• Raw file URL mask (optional)

  The raw file URL mask is a path to a raw file blob on a cgit or Gitweb server with special tags that will be substituted to build a real URL to a file in the repository. This field is needed when using Review Board with a remote Git repository.

  For example:

  • cgit: http://git.gnome.org/browse/gtk+/plain/<filename>?id2=<revision>
  • Gitweb: http://git.kernel.org/?p=bluetooth/bluez-gnome.git;a=blob_plain;f=<filename>;hb=<revision>

  This is only shown when Hosting service is set to Custom and Repository type is set to Git.

  See Raw File URLs below for more information.

• Username and Password (optional)

  Some repositories will require a username and password for access, some require only a username, and some don’t require either and instead allow for anonymous access.

  Subversion repositories, for example, generally provide anonymous access, while CVS and Perforce generally require a username but not a password.

  The administrator of the repository should know what is required. This varies depending on the setup.

  This may or may not be shown depending on Hosting service and Repository type.

Bug Tracker¶

In most projects, there’s a bug tracker associated with the repository or project, and review requests will often reference bugs.

Review Board will automatically link any bugs to the bug tracker associated with the repository if this field is provided.

• Use hosting service’s bug tracker (optional)

  If checked, and if the selected Hosting service has a built-in bug tracker, then that bug tracker will be used for this repository.

  If unchecked, a bug tracker can be specified below.

• Type (optional)

  The value of the field should be the path of a ticket, except with %s substituted for the ticket name.

  For example:

  • Bugzilla: http://bugzilla.example.com/show_bug.cgi?id=%s
  • Google Code: http://code.google.com/p/myproject/issues/detail?id=%s
  • Trac: http://trac.example.com/ticket/%s

  If you don’t use a bug tracker with projects in this repository, this field can be left blank.

Advanced¶

• Encoding (optional)

  In some cases there’s confusion as to the proper encoding to expect from files in a repository. You can set this to the proper encoding type (such as utf-8) if you need to, but generally you don’t want to touch this field if things are working fine. You can leave this blank.

When done, click Save to create the repository entry.

ClearCase¶

Review Board currently works with local ClearCase dynamic views, by utilizing version-extended paths to access specific file revisions.

The Path field should point to the top of the very top of the view, which will be either a drive letter on Windows, or a mount point on Unix.

The Username and Password fields should be blank.

CVS¶

Review Board supports several methods of connecting to a CVS server. In particular, the following connection types can be used:

• :ext:
• :fork:
• :gserver:
• :kgserver:
• :local:
• :pserver:
• :server:

If you use one of these connection types and provide it for the Path field, you won’t need to fill in the Username and Password fields.

If you use :pserver:, you can instead provide a Path of the form hostname:port/path and then specify the username and password in the appropriate fields.

Some example of valid paths include:

• cvs.example.com/cvsroot
• :pserver:anonymous@cvs.example.com/cvsroot
• :pserver:myuser:mypass@cvs.example.com:1234/cvsroot
• :local:C:\CVSROOTS\myproject

To determine the path of an existing checkout, you can go to the top-most directory of the checkout and type:

$ cat CVS/Root

You should use the contents of this file as the repository path, adjusting the username, password or path as necessary.

Git¶

In order to use Git with Review Board, you’ll need either a local clone on the server, or by using raw file URLs to a web front-end to Git (cgit, Gitweb, etc.) on the Git server. Git doesn’t have a way of fetching an individual file of a given revision from a remote server without having an entire clone, so it works differently from other repository types.

$ git remote show origin

Perforce¶

The Perforce path can be retrieved from an existing Perforce checkout by typing the following:

$ p4 info

Use the value from the Server address field.

In most setups, the Username field must be provided. This must be a user that has access to the whole repository. In some setups, this is a dedicated read-only user.

Note that Review Board will only ever use this user for read-only operations. It will never write to the repository.

Subversion¶

The Subversion path can be retrieved from an existing Subversion checkout by typing the following:

$ svn info

Use the value from the Repository Root field.

In most server setups, Subversion provides anonymous access, so the Username and Password fields won’t need to be filled out. However, this depends on the server setup. Some are more restricted and will require a dedicated user.

In Subversion setups where there’s a public anonymous URL and a secured developer URL (such as one using https or svn+ssh), you should put the public URL in Path field and your developer URL in the Mirror Path.