• Get Review Board
  • What's New
  • Products
  • Review Board Code review, image review, and document review
  • Documentation
  • Release Notes
  • Power Pack Enterprise integrations, reports, and enhanced document review
  • Try for 60 Days
  • Purchase
  • RBCommons Review Board as a Service, hosted by us
  • Pricing
  • RBTools Command line tools and Python API for Review Board
  • Documentation
  • Release Notes
  • Review Bot Automated code review, connecting tools you already use
  • Documentation
  • Release Notes
  • RB Gateway Manage Git and Mercurial repositories in your network
  • Documentation
  • Release Notes
  • Learn and Explore
  • What is Code Review?
  • Documentation
  • Frequently Asked Questions
  • Support Options
  • Third-Party Integrations
  • Demo
  • Review Board RBTools Power Pack Review Bot Djblets RB Gateway
    1. Review Board 1.0
    2. Version 7.x
    3. Version 6.x
    4. Version 5.0
    5. Version 4.0
    6. Version 3.0
    7. Version 2.5
    8. Version 2.0
    9. Version 1.7
    10. Version 1.6
    11. Version 1.5
    12. Version 1.0
    13. Administration Guide
    14. Management
    15. Managing Repositories
  • Home
  • General Index
  • Release Notes
  • This documentation covers Review Board 1.0. You can select a version above or view the latest documentation.

    Managing Repositories¶

    Review Board supports talking to multiple source code repositories of various types. A single Review Board server can be configured with nearly an unlimited number of repositories, making it useful in large projects and companies as well as small. These are managed in the Administration UI through either the database section or the Administrator Dashboard.

    Adding Repositories¶

    In order for Review Board to talk to a source code repository, it must first know how to access it.

    To add a new repository, click the Add link next to the Repositories entry in the database section or the Administrator Dashboard.

    A form will appear with the following fields:

    • 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.

    • 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.

    • 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.

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

    • 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.

    • Tool (required)

      This is the type of the repository. These values should be straightforward.

    • Bug Tracker (optional)

      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.

      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.

    • 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.

    Editing Repositories¶

    In the event that you need to change the information on a repository (for example, if the repository path or the bug tracker URL has changed), you can edit your repository information by clicking Repositories in the Administrator Dashboard or Database section of the Administration UI.

    See Adding Repositories for a description of each field.

    When done, click Save to save your changes.

    Deleting Repositories¶

    To delete a repository, follow the instructions in Editing Repositories to find the repository you want to get rid of. Then click Delete at the bottom of the page.

    Warning

    Deleting a repository will delete any and all review requests, reviews, diffs, or other data associated with it. You should never delete a repository that has been previously used, unless the server is really dead and gone with no replacement (in which case review requests won’t be able to grab the diff information anyway).

    Determining Repository Information¶

    The Path field for a repository is very dependent on the type of repository you’re configuring. This section provides some help for determining which value to use.

    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 first need a local checkout, which should be kept in sync regularly. Ideally, this checkout will be the master upstream repository, or a clone kept in sync on every commit.

    The Path field should be the full path of the .git directory inside this checkout. For example: /var/git/projectname/.git

    The Mirror path field should contain the repository URL. Find the URL you should use from within a git checkout by running the following:

    $ git remote show origin

    The value shown as URL: should be entered as the mirror path. For example: git@git.example.com:projectname.git

    The Username and Password fields should be blank.

    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.

    Keep up with the latest Review Board releases, security updates, and helpful information.

    About
    News
    Demo
    RBCommons Hosting
    Integrations
    Happy Users
    Support Options
    Documentation
    FAQ
    User Manual
    RBTools
    Administration Guide
    Power Pack
    Release Notes
    Downloads
    Review Board
    RBTools
    Djblets
    Power Pack
    Package Store
    PGP Signatures
    Contributing
    Bug Tracker
    Submit Patches
    Development Setup
    Wiki
    Follow Us
    Mailing Lists
    Reddit
    Twitter
    Mastodon
    Facebook
    YouTube

    Copyright © 2006-2025 Beanbag, Inc. All rights reserved.

    Terms of Service — Privacy Policy — AI Ethics Policy — Branding

    On this page

    • [Top]
    • Adding Repositories
    • Editing Repositories
    • Deleting Repositories
    • Determining Repository Information
      • CVS
      • Git
      • Perforce
      • Subversion