 (don't forget the ".")
    will remove the changes introduced by the second last commit (-2), without
    affecting the changes introduced by the last commit (-1).  To remove
    certain changes on a hunk-by-hunk basis, see the shelve command.
    To update the branch to a specific revision or the latest revision and
    update the working tree accordingly while preserving local changes, see the
    update command.

    Uncommitted changes to files that are reverted will be discarded.
    However, by default, any files that have been manually changed will be
    backed up first.  (Files changed only by merge are not backed up.)  Backup
    files have '.~#~' appended to their name, where # is a number.

    When you provide files, you can use their current pathname or the pathname
    from the target revision.  So you can use revert to "undelete" a file by
    name.  If you name a directory, all the contents of that directory will be
    reverted.

    If you have newly added files since the target revision, they will be
    removed.  If the files to be removed have been changed, backups will be
    created as above.  Directories containing unknown files will not be
    deleted.

    The working tree contains a list of revisions that have been merged but
    not yet committed. These revisions will be included as additional parents
    of the next commit.  Normally, using revert clears that list as well as
    reverting the files.  If any files are specified, revert leaves the list
    of uncommitted merges alone and reverts only the files.  Use ``brz revert
    .`` in the tree root to revert all files but keep the recorded merges,
    and ``brz revert --forget-merges`` to clear the pending merge list without
    reverting any files.

    Using "brz revert --forget-merges", it is possible to apply all of the
    changes from a branch in a single revision.  To do this, perform the merge
    as desired.  Then doing revert with the "--forget-merges" option will keep
    the content of the tree as it was, but it will clear the list of pending
    merges.  The next commit will then contain all of the changes that are
    present in the other branch, but without any other parent revisions.
    Because this technique forgets where these changes originated, it may
    cause additional conflicts on later merges involving the same source and
    target branches.
    )