Chapter 19. QuickRevBoard

The QuickRevBoard generates task lists and information about the review state of all files by comparing the file versions with the project files. The QuickRevBoard uses the information stored in the history database, which is stored by default in .quickRev/history in the user's home directory during normal QuickRev usage. If the history-DB is set up already nothing else has to be done. But sometimes it is necessary to create a completely new history-DB for creation of the QuickRevBoard. For doing this use QuickRev --history to create (or update) a history-DB. java -jar QuickRev --history --hel will show you all possible options. For creation of the history-DB and the QuickRevBoard --db-dir might be used the specify a different location of the history-DB.

[See]Take a look at the examples for more information.
[See]See Review History for information about updating the review history.

19.1. Command Line Options

  java -jar QuickRev.jar --board [OPTIONS]

        Prints this help.

  [--db-dir <db-dir>]
        Defines the directory where the history-DB is stored.
        If this option is omitted the database will be searched in '~/.quickRev/history'.

        Defines the used version control system.
        Either 'svn' for SVN, 'git' for GIT and 'cc' for ClearCase can be used.
        If this parameter is not given 'svn' is used as default.

    [--vcs-command <command>]
        Per default the commands 'svn' for SVN, 'git' for GIT and 'cleartool' for ClearCase are used.
        A different command can be specified here which is helpful if the default command cannot be found via the default
        search path. Furthermore it is possible to add additional options (e.g. username / password / etc.) to the command.
        Note: if additional arguments are given (or the path contains spaces) the command has to be quoted.

  [--start-dir <start-dir...>]
        Defines the start directories to search for files to be shown in the review history.

  [--exclude <path-pattern...>]
        Excludes paths (directories and files) which contain one of the regular expressions from search.
        Only the part behind the given start directory will be checked for a match.
        (increases search performance)

  [--exclude-file <paths-file>]
        Excludes paths which contain one of the regular expressions specified in the given file from search.
        Every regular expression has to be defined in a new line.

  [--include <path-pattern...>]
        Includes paths (directories and files) which contain one of the regular expressions in the final result set.
        Only the part behind the given start directory will be checked for a match.
        '--exclude' takes preference over '--include', so all paths which are excluded cannot be included via this option.
        If this option is given only paths will be included in the final result set which match one of the given include pattern.
        Includes are checked when the whole path to a file is available, while excludes are checked already during
        traversal through the directory structure. So using '--exclude' might be faster if whole directories can
        be excluded.

  [--include-file <paths-file>]
        Includes paths which contain one of the regular expressions specified in the given file in the final result set.
        Every regular expression has to be defined in a new line.

  -o|--out-dir <output-directory>
        Specifies the output directory where the output files have to be stored.

  [--replace-path <replace-from, replace-to>]
        Replacement of the paths to the project files or even the files to be reviewed.
        This option can be used to replace local paths with remote ones in the generated output files.
        If the option is given more than once the replacement which matches first will be used.

  [--replace-vcs-path <local-path, original-path>]
        Replaces the path of the read files under version control with a different one to fit to the path used in
        the project files. This can be useful for subversion mirrors or for ClearCase if the directories are mounted
        to different drives or locations.

        When creating review history for large subversion repositories the process can be increased dramatically by
        creating a local mirror of the svn repository and creating the QuickRevBoard based on the local mirror.
        One possibility is to use 'svnsync' here. Since the path of the files read from the mirrored repository does
        not fit to the original one the reviews cannot be assigned to the files. So this options allows to specify the
        path of the local mirror and replace it with the original path.
        Note: This options might work for other mirrors (like 'svk') as well, but is tested only for 'svnsync'.
              So try out for other mirrors - and please let me know whether it worked.

  [--file-version-separator <separator>]
        To access different versions of a file directly a link to every version will be created in the following form:
        for Subversion: path-to-file?p=version (e.g. http://path/
        for ClearCase : path-to-file@@version (e.g. http://path/
        Make use of this option to define a different separator between 'path-to-file' and 'version'.

        Specify this option to generate the 'json' files only and omit all stylesheet, html, image,
        and other visualisation related files. So only the data structure will be generated and you can use your own
        visualisation, evaluation or whatever tools.

        Specify this options to suppress generation of the task list.

        Specify this options to suppress generation of the files review history.

  [--baseline <number/label/tag>]
        Defines a revision number / label / tag which will be used as baseline.
        I.e. all file versions which are older or equal to the given number will be regarded as 'reviewed'.
        This option is available for the following version control systems: SVN / ClearCase.

  [--baseline-time <yyyy-MM-dd/hh:mm:ss>]
        Defines a time point which will be used as baseline.
        I.e. all file versions which are older or equal to the given time point will be regarded as 'reviewed'.
        This option is available for all version control systems.

        Changes the number of threads to determine the file history.
        To increase the performance try different values.
        If this option is not given the number of processors is used as default.

  [-c|--config <config-file...>]
        Make use of this option to load the same configuration files as for normal QuickRev usage.

  [--plugin <plugin-path...>]
        Make use of this option to load the same plugin files as for normal QuickRev usage.

        This option is useful in case of errors to get additional information.
        Specifying "--debug" only, will show an additional "Debug" menu which provides different debug options.
        Furthermore you can assign a log-level in the form "--debug:ALL" to print logging information of the
        given level to standard error. The following log-levels are available:
        SEVERE (highest value), WARNINGINFOCONFIGFINEFINERFINEST (lowest value), ALL.
        (See java.util.logging.Level for more information)

[See]For some examples see Example Usage

Get QuickRev at Fast, secure and Free Open Source software downloadsCopyright 2008 - 2018 Tom SeidelLast Update: 2018-1-27