Checkin Command

Article
08/20/2007

Commits pending changes in the current workspace to the Team Foundation source control server.

tf checkin [/author:author name] [/comment:("comment"|@comment file)] 
[/noprompt] [/notes:(“Note Name”=”note text”|@notefile)] 
[/override:reasonfile|@reason] [/recursive] [/saved] [/validate] 
[filespec]

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.
Filespec	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	This option takes no arguments. 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. Any problems, such as conflicts, can be resolved.

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 source 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.

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 source 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 source 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 the base version of an item in the list of pending changes differs from the latest Team Foundation source control server version, Team Foundation prompts you to resolve conflicts between your version and the latest Team Foundation source control server version first. For example, if you checked out version 4 of stellar.cs and the latest Team Foundation source 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 pending changeset in the Team Foundation source control server and evaluated to make sure that the Team Foundation source 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 source 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

Security

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.

Checkin Command

Parameters

Remarks

The Check-in Process

Examples

Security

See Also

Tasks

Reference

Concepts

Other Resources

Additional resources