post¶
rbt post simplifies both creating and updating review requests. It can look at your source directory, generate a diff, and upload it to a new or existing review request on an associated Review Board server. This saves a lot of time over the web UI, and for some types of code repositories (such as Perforce), it’s actually required in order to produce a compatible diff.
Usage¶
$ rbt post [options] [revisions]
Posting and Updating Review Requests¶
Depending on the repository type, rbt post will either require a changeset number, or it will rely on the changes in the current source tree. The end result is that rbt post will build a diff and post it to a Review Board server. The diff and any additional review request information will be saved on the server as a draft, which can then be published.
After posting a new review request or updating an existing one,
rbt post will display the URL of the review request. If the
-o
parameter is passed, the default web browser will be opened
to that URL.
The following subsections will explain how rbt post is used with different repository types.
Perforce¶
Posting Changesets¶
Perforce has a concept of changesets, which are server-stored descriptions of a change along with an ID number and associated files. For Perforce, Review Board stores changeset numbers of a posted change and can use these to associate particular changes with review requests.
To post a review request for a specific change, or to update an existing review request for that change, type:
$ rbt post CHANGENUM
Where CHANGENUM
is a pending or shelved changeset number in Perforce.
Note
When CHANGENUM
refers to a shelved changeset which does not have opened
files in the client, any moved files within the change will be shown as a
deleted file and an added file. This is due to limitations in Perforce’s
interface for shelved changesets.
The diff will be generated and uploaded to Review Board, and the review request information will be updated based on the changeset description.
rbt post must be used if you’re using Perforce with Review Board, as the diff generated by p4 diff doesn’t provide the information necessary to properly display a side-by-side diff.
Posting Paths¶
There are cases where you may want to post individual paths containing files instead of changesets. Take the following cases, for example:
You have code or other files that must be checked in before they’re reviewed and have undergone multiple changes.
You’re working in a side branch for a while, possibly with other people, and need to review the code before it’s integrated into the main branch.
You want to post a really old, previously abandoned change for review that previously went unreviewed.
To post with a path, rbt post should be run with a standard Perforce depot path as a parameter, which may contain revision information. The following paths are supported:
Uploading a file as a “new” file:
//path/to/file
Uploading all files in a directory as “new” files:
//path/to/dir/...
Uploading a file from a revision as a “new” file (not as common):
//path/to/file/[@#]rev
Uploading a diff of a file between two revisions:
//path/to/file[@#]rev,[@#]rev
Uploading a diff of all files between two revisions in a directory:
//path/to/dir/...[#@]rev,[#@]rev
CVS and Subversion¶
CVS and Subversion don’t have a concept of changesets, so instead the working copy’s uncommitted changes are posted for review. To post a review request with all uncommitted files in a tree, simply run:
$ rbt post
This will create a new review request and post the diff of the uncommitted
changes. If you want to update an existing review request with new changes
instead, use the -r
parameter. For example, to update
review request #42, type:
$ rbt post -r 42
If you need to post specific files, leaving other uncommitted files out of the review request, you can include them on the command line, like so:
$ rbt post -I src/foo.c -I data/bar.png
Distributed Version Control Systems¶
When using a distributed version control system, such as Git or Mercurial,
rbt post will by default post the diff between the current
branch and the master
branch. To post a new review request with the
diff between the current branches commit, and the master branch, simply run:
$ rbt post
If you’d like to update an existing review request with new changes instead,
use the -u
parameter. This will attempt to locate the matching
review request for your change’s commit message.
$ rbt post -u
If you want to update a specific review request by ID, you can use the
-r
parameter:
$ rbt post -r 42
In the case where you are working on code based on a branch that isn’t available to the repository Review Board has configured, you’ll want to take advantage of rbt post’s parent diff support.
A parent diff is a diff between some known upstream revision that Review Board has access to and the parent of your branch. It’s used to provide a working baseline for your branch’s diff.
For example, in the case of Git, you may be working on the topicB
branch,
which has an ancestry that looks like:
o master
\
o---o topicA
\
o---o topicB
If you want to upload a diff of everything between topicA
and topicB
,
you would need to tell rbt post to also generate a parent diff
between master
and topicA
.
This is done by using the --parent
parameter with the branch name.
For example, in this case you would simply do:
$ rbt post --parent=topicA
That would generate a parent diff between master
and topicA
, and
a normal diff of your changes between topicA
and topicB
. The changes
in the parent diff won’t appear as changed lines in the diff viewer, meaning
that users will only see changes made between topicB
and topicA
.
Tracking Branches¶
When using Git, rbt post makes the assumption that the closest
upstream branch for the diff will be origin/master
. This may be wrong if
you are working on a feature branch or have a remote named something other than
origin
.
In this case, you will want to use the --tracking-branch
option,
which specifies the remote branch name. For example:
$ rbt post --tracking-branch=upstream/master
ClearCase and VersionVault¶
Changed in version 3.0: As of Version 3.0, RBTools supports both the legacy “ClearCase” repository type, as well as the new “VersionVault” type which is a part of Power Pack. VersionVault can be used with both IBM ClearCase as well as HCL VersionVault, and is the recommended implementation to use.
rbt post provides support for posting changes using IBM ClearCase or HCL VersionVault repositories. There are several different modes which can be used depending on how you’ve organized your repository. Changes must be posted from within a snapshot or dynamic view.
The most simple case is posting a diff of all currently checked out files in your view. This will work no matter what workflow you are using:
$ rbt post
To post a change between a branch and its predecessor, use:
$ rbt post brtype:branchname
To post a change between a label and its predecessor, use:
$ rbt post lbtype:labelname
A diff between two labels can also be posted. This requires posting from within a dynamic view:
$ rbt post lbtype:label1 lbtype:label2
If you’re using UCM, you can also post activities, baselines, and streams:
$ rbt post activity:my-activity
$ rbt post baseline:project-dev
$ rbt post baseline:project-integration baseline:project-dev
$ rbt post stream:dev-stream
Finally, you can also assemble a diff using file@revision pairs. This requires
posting from within a dynamic view. Each argument will be a
file@@revision1:file@@revision2
pair:
$ rbt post /vobs/proj/file.c@@/main/0:/vobs/proj/file.c@@/main/1
Multiple files can be posted by adding additional file/revision pairs:
$ rbt post /vobs/proj/file.c@@/main/0:/vobs/proj/file.c@@/main/1 \
/vobs/proj/file.h@@/main/0:/vobs/proj/file.h@@/main/1
Note
Without any configuration, rbt post tries to match Review Board’s
repository based on the VOB’s family UUID, and may fall back to trying to
match the name with the VOB tag. In both these cases, the match may be slow.
It’s highly recommended to set REPOSITORY
in .reviewboardrc
or
use the --repository
command-line option.
Note
There are two ways that ClearCase repositories may be configured on the Review Board server. If the repository is using the community-driven ClearCase backed, review requests may only contain changes from a single VOB. If the repository uses the newer VersionVault backend, changes may span across multiple VOBs.
Cliosoft SOS¶
New in version 3.1.
rbt post provides support for posting changes using Cliosoft SOS 7.20 or higher. It supports posting changelists (recommended) or selections.
See Using RBTools With Cliosoft SOS for a detailed guide.
Posting Changelists¶
Changelists can be posted by passing a changelist name to rbt post. For example:
$ rbt post my-changelist
You can then update the review request that matches that changelist by using
-u
:
$ rbt post -u my-changelist
Posting Selections¶
To post a default selection (which includes all modified files, or files added to/removed from checked-out directories):
$ rbt post
To post an explicit SOS selection:
$ rbt post "select:<flags>"
# For example:
$ rbt post "select:-scm -sor -sunm"
You can update the review request by using -r
and passing the ID
of the review request you created. Make sure to pass in any selections along
with this. Examples include:
$ rbt post -r 123
$ rbt post -r 123 "select:-scm -sor -sunm"
Posting Committed Code¶
By default, rbt post assumes that you’re posting uncommitted code. This is called a pre-commit review. However, it’s sometimes useful to post code that has already been committed to a repository, such as in an experimental branch. This is a post-commit review.
In order to do this, you can pass in revisions as arguments, which will generate a diff based on a range of committed revisions. This allows a single review request to show a diff representing the entire history of a branch, if desired.
Usage is easy. Simply type:
$ rbt post STARTREV STOPREV
Where STARTREV
is the beginning revision in the range, and
STOPREV
is the ending revision, inclusive. If you only need to post
a single revision, you can type:
$ rbt post REVISION
The syntax for revisions and revision ranges is as close to possible as the
native syntax for the underlying revision control system. You can therefore
pass in ranges either as separate arguments, or using a native range syntax
(such as R1:R2
for SVN or R1..R2
for Git).
Posting Existing Diffs¶
rbt post will generate diffs automatically based on the
repository type, but if you need to post a pre-existing diff, you can
use the --diff-filename
parameter to specify the path to
the diff file.
For example:
$ rbt post --diff-filename=mycode.diff
You can also use the special value of -
to pipe a diff into STDIN:
$ cat mycode.diff | rbt post --diff-filename=-
Using STDIN will require either a valid cookie, or the --username
and --password
options.
Auto-Setting Summary and Description¶
The summary and description of a review request can be automatically
set (“guessed”) based on the posted commit by using the
-g/--guess-fields
, --guess-summary
, or
--guess-description
options.
This saves some time when creating a review request by allowing you to write a thorough summary and description only once in the commit, and reusing it for the review request.
This feature only works for SCMs where you’re posting commits, instead of changes from a working directory. For example, Git, Mercurial and Bazaar.
Tip
-g/--guess-fields
implies --guess-summary
and
--guess-description
. Generally, you’ll want to use it instead
of the more specific options.
Controlling Guessing Behavior¶
New in version 0.6.
The guessing options can each take a value to control when guessing is done:
yes
– Guessing will be used when creating or updating the review request.no
– Guessing will not be used. This is useful for overriding a default (see Configuring Defaults).auto
– Guessing will be used only if creating a new review request, and not when updating.
You can specify a value when using either short-form or long-form arguments. For example:
$ rbt post --guess-fields=no
By default, if no guessing options are specified, --guess-fields=auto
will
be implied. This allows you to run the following and have it automatically
fill in the summary and description:
$ rbt post
If specifying a guessing argument without a value, yes
will be implied
instead, forcing the fields to be updated, regardless of the default. For
example:
$ rbt post -g
Configuring Defaults¶
Changed in version 0.6.
Projects that want to change the default guess behavior can set the
GUESS_FIELDS
, GUESS_SUMMARY
, and GUESS_DESCRIPTION
settings
in .reviewboardrc
. These accept 'yes'
, 'no'
, and 'auto'
values.
On RBTools 0.6 or higher, the default is 'auto'
. On older versions,
the default was False
(equivalent to 'no'
).
Setting GUESS_FIELDS
will imply setting GUESS_SUMMARY
and
GUESS_DESCRIPTION
. Rarely will you need to set anything but
GUESS_FIELDS
.
For example, to default to guessing fields for review requests that are either newly created or being updated, you can use:
GUESS_FIELDS = 'yes'
Automating rbt post¶
It’s possible to automate rbt post on a user’s behalf. This can
be useful from a repository’s post-commit hook to automatically
create or update a review request. This works through a combination of a
special Review Board user and the --submit-as
option.
To set this up, first register a new user. This user will be specific to your script, and will have special permissions, so make sure the password is protected. You’ll then want to grant the “Can submit as user” Permission and “Can edit review request” Permission to the user. This will give this user to the ability to modify a review request as another user.
You can then invoke rbt post by doing the following:
$ rbt post --username=SPECIAL_USER \
--password=PASSWORD \
--submit-as=ANOTHER_USER
Of course, you can pass any other values as you see fit.
This will log in as SPECIAL_USER
and perform operations as
ANOTHER_USER
.
You can set the default for --submit-as
by setting SUBMIT_AS
in .reviewboardrc
.
JSON Output¶
New in version 3.0.
When running with --json
, the results of posting the review request
will be outputted as JSON. This can be used by programs that wrap RBTools in
order to automate posting changes for review.
Successful Payloads¶
When posting is successful, the results are in the form of:
{
"status": "success",
// The path to the new diff.
"diff_url": "<string>",
// The ID of the review request.
"review_request_id": <int>,
// The URL of the review request.
"review_request_url": "<string>"
}
For example:
$ rbt post --json my-branch
{
"diff_url": "https://example.com/r/123/diff/",
"review_request_id": 123,
"review_request_url": "https://example.com/r/123/"
}
Error Payloads¶
When there’s an error posting a change for review, the results will be in the form of:
{
"status": "failed",
// A list of errors from the operation.
"errors": [
"<string>",
...
]
}
For example:
$ rbt post --json my-branch
{
"errors": [
"Could not find the repository on the Review Board server."
],
"status": "failed"
}
Options¶
- -d, --debug¶
Displays debug output.
This information can be valuable when debugging problems running the command.
The default can be set in
DEBUG
in .reviewboardrc.
- --json¶
Output results as JSON data instead of text.
The default can be set in
JSON_OUTPUT
in .reviewboardrc.New in version 3.0.
Posting Options¶
Controls the behavior of a post, including what review request gets posted and how, and what happens after it is posted.
- -u, --update¶
Automatically determines the existing review request to update.
New in version 0.5.3.
- -r <id>, --review-request-id <id>¶
Specifies the existing review request ID to update.
- -p, --publish¶
Publishes the review request immediately after posting.
All required fields must already be filled in on the review request or must be provided when posting.
The default can be set in
PUBLISH
in .reviewboardrc.
- -t, --trivial-publish¶
Publish the review request immediately after posting, but without sending an e-mail notification.
New in version 1.0.
- -o, --open¶
Opens a web browser to the review request after posting.
The default can be set in
OPEN_BROWSER
in .reviewboardrc.
- -s, --stamp¶
Stamps the commit message with the review request URL while posting the review.
The default can be set in
STAMP_WHEN_POSTING
in .reviewboardrc.New in version 0.7.3.
- --submit-as <username>¶
The username to use as the author of the review request, instead of the logged in user.
This is useful when used in a repository’s post-commit script to update or create review requests. See Automating rbt post for more information on this use case.
The default can be set in
SUBMIT_AS
in .reviewboardrc.
- --change-only¶
Updates fields from the change description, but does not upload a new diff (Perforce/Plastic only).
- --diff-only¶
Uploads a new diff, but does not automatically update fields from the commit message/change description. Fields explicitly provided by other options will be ignored.
- -S, --squash-history¶
Force the review request to be created without history, even if the server supports it. Uploaded diffs will be squashed together.
The default can be set in
SQUASH_HISTORY
in .reviewboardrc.New in version 2.0.
- -H, --with-history¶
Force the review request to be created with history if the server supports it.
This option overrides the SQUASH_HISTORY
.reviewboardrc
option and the -S command line option.New in version 2.0.
Review Board Server Options¶
Options necessary to communicate and authenticate with a Review Board server.
- --server <url>¶
Specifies the Review Board server to use.
The default can be set in
REVIEWBOARD_URL
in .reviewboardrc.
- --username <username>¶
The user name to be supplied to the Review Board server.
The default can be set in
USERNAME
in .reviewboardrc.
- --password <password>¶
The password to be supplied to the Review Board server.
The default can be set in
PASSWORD
in .reviewboardrc.
- --ext-auth-cookies <ext auth cookies>¶
Use an external cookie store with pre-fetched authentication data. This is useful with servers that require extra web authentication to access Review Board, e.g. on single sign-on enabled sites.
The default can be set in
EXT_AUTH_COOKIES
in .reviewboardrc.New in version 0.7.5.
- --api-token <token>¶
The API token to use for authentication, instead of using a username and password.
The default can be set in
API_TOKEN
in .reviewboardrc.New in version 0.7.
- --disable-proxy¶
Prevents requests from going through a proxy server.
The default can be set in
ENABLE_PROXY
in .reviewboardrc.
- --disable-ssl-verification¶
Disable SSL certificate verification. This is useful with servers that have self-signed certificates.
The default can be set in
DISABLE_SSL_VERIFICATION
in .reviewboardrc.New in version 0.7.3.
- --disable-cookie-storage¶
Use an in-memory cookie store instead of writing them to a file. No credentials will be saved or loaded.
The default can be set in
SAVE_COOKIES
in .reviewboardrc.New in version 0.7.3.
- --disable-cache¶
Disable the HTTP cache completely. This will result in slower requests.
The default can be set in
DISABLE_CACHE
in .reviewboardrc.New in version 0.7.3.
- --disable-cache-storage¶
Disable storing the API cache on the filesystem, instead keeping it in memory temporarily.
The default can be set in
IN_MEMORY_CACHE
in .reviewboardrc.New in version 0.7.3.
- --cache-location <file>¶
The file to use for the API cache database.
The default can be set in
CACHE_LOCATION
in .reviewboardrc.New in version 0.7.3.
- --ca-certs <file>¶
Additional TLS CA bundle.
The default can be set in
CA_CERTS
in .reviewboardrc.
- --client-key <file>¶
Key for TLS client authentication.
The default can be set in
CLIENT_KEY
in .reviewboardrc.
- --client-cert <file>¶
Certificate for TLS client authentication.
The default can be set in
CLIENT_CERT
in .reviewboardrc.
- --proxy-authorization <proxy authorization>¶
Value of the Proxy-Authorization header to send with HTTP requests.
The default can be set in
PROXY_AUTHORIZATION
in .reviewboardrc.
Repository Options¶
- --repository <name>¶
The name of the repository configured on Review Board that matches the local repository.
The default can be set in
REPOSITORY
in .reviewboardrc.
- --repository-url <url>¶
The URL for a repository.
When generating diffs, this can be used for creating a diff outside of a working copy (currently only supported by Subversion with specific revisions or
--diff-filename
, and by ClearCase with relative paths outside the view).For Git, this specifies the origin URL of the current repository, overriding the origin URL supplied by the client.
The default can be set in
REPOSITORY_URL
in .reviewboardrc.Changed in version 0.6: Prior versions used the
REPOSITORY
setting in.reviewboardrc
, and allowed a repository name to be passed to--repository-url
. This is no longer supported in 0.6 and higher. You may need to update your configuration and scripts appropriately.
- --repository-type <type>¶
The type of repository in the current directory. In most cases this should be detected automatically, but some directory structures containing multiple repositories require this option to select the proper type. The rbt list-repo-types command can be used to list the supported values.
The default can be set in
REPOSITORY_TYPE
in .reviewboardrc.
Review Request Field Options¶
Options for setting the contents of fields in the review request.
- -f <field name=value>, --field <field name=value>¶
Sets custom fields into the extra_data of a review request. Can also be used to set built-in fields like description, summary, testing-done.
- -g [auto|yes|no], --guess-fields [auto|yes|no]¶
Equivalent to setting both
--guess-summary
and--guess-description
.This can optionally take a value to control the guessing behavior. See Controlling Guessing Behavior for more information.
If not specified,
auto
is used by default. The default can be changed by settingGUESS_FIELDS
in .reviewboardrc.
- --guess-summary <auto|yes|no>¶
Generates the Summary field based on the commit messages (Bazaar/Git/Mercurial only).
This can optionally take a value to control the guessing behavior. See Controlling Guessing Behavior for more information.
The default can be set in
GUESS_SUMMARY
in .reviewboardrc.
- --guess-description <auto|yes|no>¶
Generates the Description field based on the commit messages (Bazaar/Git/Mercurial only).
This can optionally take a value to control the guessing behavior. See Controlling Guessing Behavior for more information.
The default can be set in
GUESS_DESCRIPTION
in .reviewboardrc.
- -m <text>, --change-description <text>¶
A description of what changed in this update of the review request. This is ignored for new review requests.
- --summary <text>¶
The new contents for the Summary field.
- --description <text>¶
The new contents for the Description field.
- --description-file <filename>¶
A text file containing the new contents for the Description field.
- --testing-done <text>¶
The new contents for the Testing Done field.
- --testing-done-file <filename>¶
A text file containing the new contents for the Testing Done field.
- --branch <branch>¶
The branch the change will be committed on or affects. This is a free-form field and does not control any behavior.
The default can be set in
BRANCH
in .reviewboardrc.
- --bugs-closed <bug id[,...]>¶
The comma-separated list of bug IDs closed.
- --target-groups <name[,...]>¶
The names of the groups that should perform the review.
- --target-people <username[,...]>¶
The usernames of the people who should perform the review.
- --depends-on <id[,...]>¶
A comma-separated list of review request IDs that this review request will depend on.
The default can be set in
DEPENDS_ON
in .reviewboardrc.New in version 0.6.1.
- --markdown¶
Specifies if the summary, description, and change description should should be interpreted as Markdown-formatted text.
This is only supported in Review Board 2.0+.
The default can be set in
MARKDOWN
in .reviewboardrc.New in version 0.6.
Diff Generation Options¶
Options for choosing what gets included in a diff, and how the diff is generated.
- --no-renames¶
Add the
--no-renames
option to the git when generating diff.Supported by: Git
New in version 0.7.11.
- --revision-range <rev1:rev2>¶
Generates a diff for the given revision range.
Deprecated since version 0.6.
- -I <filename>, --include <filename>¶
Includes only the specified file in the diff. This can be used multiple times to specify multiple files.
Supported by: Bazaar, CVS, Git, Mercurial, Perforce, SOS, and Subversion.
New in version 0.6.
- -X <pattern>, --exclude <pattern>¶
Excludes all files that match the given pattern from the diff. This can be used multiple times to specify multiple patterns. UNIX glob syntax is used for pattern matching.
Supported by: Bazaar, CVS, Git, Mercurial, Perforce, SOS, and Subversion.
Patterns that begin with a path separator (/ on Mac OS and Linux, on Windows) will be treated as being relative to the root of the repository. All other patterns are treated as being relative to the current working directory.
For example, to exclude all “.txt” files from the resulting diff, you would use “-X /’*.txt’”.
When working with Mercurial, the patterns are provided directly to “hg” and are not limited to globs. For more information on advanced pattern syntax in Mercurial, run “hg help patterns”
When working with CVS all diffs are generated relative to the current working directory so patterns beginning with a path separator are treated as relative to the current working directory.
When working with Perforce, an exclude pattern beginning with
//
will be matched against depot paths; all other patterns will be matched against local paths.The default can be set in
EXCLUDE_PATTERNS
in .reviewboardrc.New in version 0.7.
- --parent <branch>¶
The parent branch this diff should be generated against (Bazaar/Git/Mercurial only).
The default can be set in
PARENT_BRANCH
in .reviewboardrc.
- --diff-filename <filename>¶
Uploads an existing diff file, instead of generating a new diff.
Branch Options¶
Options for selecting branches.
- --tracking-branch <branch>¶
The remote tracking branch from which your local branch is derived (Git/Mercurial only).
For Git, the default is to use the remote branch that the local branch is tracking, if any, falling back on
origin/master
.For Mercurial, the default is one of:
reviewboard
,origin
,parent
, ordefault
.The default can be set in
TRACKING_BRANCH
in .reviewboardrc.
Git Options¶
Git-specific options for diff generation.
- --git-find-renames-threshold <threshold>¶
The threshold to pass to :option:–find-renames`` when generating a git diff.
For more information, see
git help diff
.
Perforce Options¶
Perforce-specific options for selecting the Perforce client and communicating with the repository.
- --p4-client <client name>¶
The Perforce client name for the repository.
The default can be set in
P4_CLIENT
in .reviewboardrc.
- --p4-port <port>¶
The IP address for the Perforce server.
The default can be set in
P4_PORT
in .reviewboardrc.
- --p4-passwd <password>¶
The Perforce password or ticket of the user in the P4USER environment variable.
The default can be set in
P4_PASSWD
in .reviewboardrc.
Subversion Options¶
Subversion-specific options for controlling diff generation.
- --basedir <path>¶
The path within the repository where the diff was generated. This overrides the detected path. Often used when passing
--diff-filename
.The default can be set in
BASEDIR
in .reviewboardrc.
- --svn-username <username>¶
The username for the SVN repository.
- --svn-password <password>¶
The password for the SVN repository.
- --svn-prompt-password¶
Prompt for the user’s svn password. This option overrides the password provided by the
--svn-password
option.The default can be set in
SVN_PROMPT_PASSWORD
in .reviewboardrc.New in version 0.7.3.
- --svn-show-copies-as-adds <y|n>¶
Treat copied or moved files as new files.
This is only supported in Subversion 1.7+.
New in version 0.5.2.
- --svn-changelist <id>¶
Generates the diff for review based on a local changelist.
Deprecated since version 0.6.
TFS Options¶
Team Foundation Server specific options for communicating with the TFS server.
- --tfs-login <tfs login>¶
Logs in to TFS as a specific user (ie.user@domain,password). Visit https://msdn.microsoft.com/en-us/library/hh190725.aspx to learn about saving credentials for reuse.
- --tf-cmd <tf cmd>¶
The full path of where to find the tf command. This overrides any detected path.
The default can be set in
TF_CMD
in .reviewboardrc.
- --tfs-shelveset-owner <tfs shelveset owner>¶
When posting a shelveset name created by another user (other than the one who owns the current workdir), look for that shelveset using this username.