Jump to >

Server Import and Export

New in version 4.0.

There are times when you may want to take the content from one Review Board server and move it to another. The simplest way to do this is just to copy the database, but there are some times when that will not suffice:

  • You want to export only a subset of the content (for example, if part of a business is being spun-out or acquired).

  • You want to combine two separate Review Board instances into one.

  • You want to change database backend types (for example, moving from MySQL to Postgres).

For these cases, Power Pack’s import/export feature comes to the rescue. The exporter will allow you to select what data you want to include, and will create a serialized, database-independent representation. The importer can then take that bundle and load all the data into the new database. The importer provides various strategies to allow you to control the behavior when conflicts arise (for example, when two user entries have the same username).

Export

The export-db command will export a whole or partial database

$ rb-site manage /path/to/site export-db

This will create a directory with the exported data bundle, as well as a key file. Any sensitive information (for example, credentials for repositories) within the bundle will be encrypted with the key file.

Important

The database is not locked during the export process. In order to ensure consistency, we recommend that you enable read-only mode on the server, or export from a backup copy of the database.

Choosing the Output Location

The export command will, by default, write the exported data to a directory with the format reviewboard-export.YYMMDD-HHMMSS. If you would like to change this, use --out-dir

$ rb-site manage /path/to/site export-db -- \
    --out-dir=reviewboard-export

Selecting Review Requests

By default, the export command will export all review requests on the site. This can be limited by passing in a list of review request IDs, either via the command-line, or in a file.

To limit the review requests via the command-line, run

$ rb-site manage /path/to/site export-db -- \
    --review-requests=1,3,5,10:20,25

The format for this is a comma-separated list of IDs without any spaces. Ranges can be included using the id1:idN format.

If you have a large number of review requests to export, you can put this list into a file. In this case, instead of separating IDs by commas, separate them with newlines

$ rb-site manage /path/to/site export-db -- \
    --review-requests-file=review-request-ids.txt

When limiting based on review request IDs, the export command will only include those users who participated in those review requests. If you want the export to include all users on the server or local site instead, use --all-users

$ rb-site manage /path/to/site export-db -- \
    --review-requests=2 --all-users

Import

The import-db command will import a bundle into the server

$ rb-site manage /path/to/site import-db -- \
    -b reviewboard-export.220315-105123/bundle \
    -k reviewboard-export.220315-105123/key

Important

We recommend that you test the import on a copy of your database before trying it in production.

Important

While the versions of Review Board on two servers do not have to match, you cannot import a bundle exported from a newer version into an older version.

Resolving Conflicts

There are several object types in Review Board that have names which are expected to be unique. If the imported data conflicts with existing data, the default is to abort the import operation (in this event, the abort will happen before any data is actually written to the database). Different object types support different strategies:

abort

Abort the import operation. This is the default.

merge

Merge the conflicting objects. For example, two repositories may exist with the same name, and merging will combine all review requests together into a single repository.

rename

Rename the conflicting objects. The renamed objects will have an imported- prefix added to the name.

User conflicts can be resolved with --user-strategy. This supports abort, merge, and rename

$ rb-site manage /path/to/site import-db -- \
    -b reviewboard-export.220315-105123/bundle \
    -k reviewboard-export.220315-105123/key \
    --user-strategy=merge

Review Group conflicts can be resolved with --review-group-strategy. This supports abort, merge, and rename

$ rb-site manage /path/to/site import-db -- \
    -b reviewboard-export.220315-105123/bundle \
    -k reviewboard-export.220315-105123/key \
    --review-group-strategy=rename

Hosting Service Account conflicts can be resolved with --hosting-account-strategy. This supports abort and merge

$ rb-site manage /path/to/site import-db -- \
    -b reviewboard-export.220315-105123/bundle \
    -k reviewboard-export.220315-105123/key \
    --hosting-account-strategy=merge

Repository conflicts can be resolved with --repository-strategy. This supports abort, merge, and rename

$ rb-site manage /path/to/site import-db -- \
    -b reviewboard-export.220315-105123/bundle \
    -k reviewboard-export.220315-105123/key \
    --repository-strategy=rename