Checkin Command
Commits pending changes in the current workspace to the Team Foundation version control server.
Required Permissions
To use the checkin command you must have the Check in permission set to Allow. To use /author option, you must have Check in other user's changes permission set to Allow. For more information, see Team Foundation Server Permissions.
tf checkin [/author:author name] [/comment:("comment"|@comment file)]
[/noprompt] [/notes:("Note Name"="note text"|@notefile)]
[/override:reasonfile|@reason] [/recursive] [/saved] [/validate]
[itemspec]
Parameters
Argument |
Description |
|---|---|
authorname |
The user-provided value for the /author option. |
comment |
A user-provided comment about the check-in. |
@comment file |
The user-provided path of a file on disk that contains the comment for the check-in. |
NoteFieldName=NoteFieldValue |
Sets the value of the check-in note field. You can provide multiple, semicolon-separated "field=value" expressions. |
Notefile |
The user-provided path of a file on disk that contains check-in note field names and values in the format of "field=value" A semicolon separated note tile can span multiple lines, for example: field1=value1; field2=value that spans multiple lines;. |
Reasonfile |
A user-provided description of the reason why the check-in policy is being ignored. If a reason is specified, a notification of the policy override and this explanation is sent to Team Foundation administrators by e-mail. |
itemspec |
Specifies a file or folder to check-in. For more information about how Team Foundation parses a file specification to determine which items are within its scope, see Command-Line Options. |
Option |
Description |
|---|---|
/author |
Identifies the author of the specified or implied the pending changes so that one user can check in changes on behalf of another user. Requires the CheckinOther permission. |
/comment |
Associates a comment with the changeset. |
/noprompt |
Suppresses any prompts for input from you. |
/notes |
Provides one or more check-in notes to associate with the changeset. |
/override |
Lets you override a check-in policy failure. This option is only needed when there is a check-in policy and you want to check in anyway. |
/recursive |
Checks in all items in the specified or implied working folder and subfolders. |
/saved |
When a check-in fails or is canceled by the user, or when the user unshelves changes, the selected changes, comment, work items, checkin notes, and checkin policy override reason, if any, are stored on the computer. When combined with /noprompt, the /saved option checks in the changes with the comment, etc. that were saved, if any. |
/validate |
The /validate option lets you test checking in without actually doing it. The /validate options causes checkin to evaluate checkin policies, check check-in notes, and look for conflicts without actually checking in. Before you check in the item, you must resolve any problems, such as conflicts, that this option identifies. |
Remarks
A pending change consists of a file or folder addition, deletion, rename, edit, branch, undelete or filetype. Some changes, such as edit and rename, can be applied at the same time to a single item. A pending change is one that has not been submitted for check-in. For more information about and a complete list of pending changes in Team Foundation, see Pending Changes.
The checkin command creates a changeset in the Team Foundation version control server from a dynamically-defined set of pending changes, work items, user-defined comments, and system metadata and makes your changes available to other users. Other users can use the get command to retrieve your changes. The history and changeset commands show changeset information for the changes you have submitted.
Note
Because you can check in pending changes from the command line, it is possible that the Source Control Explorer context menu is not always synchronized to the status of the pending changes.
For more information on how to find the tf command-line utility, see Tf Command-Line Utility Commands.
The Check-in Process
The check-in operation is performed atomically, which means that the operation either succeeds completely or fails completely. If any one of the changes in the list of pending changes cannot be submitted to the Team Foundation version control server, not one of the changes is committed and a changeset is not created. For example, if you lose network connectivity in the middle of the operation, the whole operation fails.
The first step in the check-in process is to evaluate the pending changes for compliance with check-in policies. You can override check-in policy failures at the command-line using the /override option. You must supply a reason why policy failures are being overridden. This reason is persisted in the Team Foundation version control server and becomes an attribute of the committed changeset. The /override option is primarily intended for use in scripts. For more information, see How to: Override a Check-In Policy.
If a version of an item in the list of pending changes differs from the latest Team Foundation version control server version, Team Foundation prompts you to resolve conflicts between your version and the latest Team Foundation version control server version first. For example, if you checked out version 4 of stellar.cs and the latest Team Foundation version control server version is now version 6, you are prompted to resolve conflicts. Unless the /noprompt option is specified, the Resolve dialog box appears to help you investigate and resolve version differences. After you resolve differences and re-test your code, you can try to check in your changes again.
Examples
The following example displays the Check In dialog box that has pending changes pre-selected for a bulk check-in operation of all pending changes in the workspace mapped to c:\projects. If you click Check In, each item is individually submitted to a changeset in the Team Foundation version control server and evaluated to make sure that the Team Foundation version control server version is unchanged because the item was checked out. If the check-in succeeds, Team Foundation creates a changeset and displays its number for later reference.
c:\projects>tf checkin
The following example submits all pending changes in the current workspace to the Team Foundation version control server together with the specified comment to create a new changeset.
c:\projects>tf checkin /comment:"Re-implemented Pi calculator" /noprompt
The following example submits pending changes to 314.cs and leaves all other revisions in the current workspace as pending.
c:\projects>tf checkin 314.cs /noprompt
See Also
Tasks
Walkthrough: Working with Team Foundation Version Control from the Command Line
Walkthrough: Customizing Check-In Policies and Notes
How to: Check In Pending Changes
Concepts
Submitting Changes to the Version Control Server
Reference
Command-Line Syntax (Team System)