Submitting and Undoing Pending Changes (Team Explorer Everywhere)
You can check in changes to Team Foundation version control files into the version control server by using the Pending Changes view or the Check In dialog box. Changes are checked in as a group and tracked on the server as a changeset. During a check-in, you can add explanatory comments, associate work items with the changeset, and review adherence to check-in policy. Various aspects of the check-in process can be customized by your server administrator.
When you initiate a check-in operation, the source file updates either succeed as a group or fail as a group. If any of the changes in the list of pending changes cannot be submitted to the server (for example, because of a conflict), none of the changes are committed and a changeset is not created.
During a check-in operation:
Compliance with check-in policy is validated.
The changes are committed to the server as a changeset.
Files that were checked out are returned to a read-only state. Your changes appear in the server and can be retrieved by other users.
E-mail is delivered to team members who have subscribed for check-in notification.
In Team Explorer Everywhere 2010, you cannot subscribe for check-in notification. If you use another client of Team Foundation Server to configure the subscriptions, you can receive emails when check-ins occur.
Work items are updated.
An administrator for Team Foundation can configure the check-in notes and check-in policies that apply to a given team project. For more information, see Setting and Enforcing Quality Gates (Team Explorer Everywhere).
View and manage pending changes: Understand the types of locally-persisted changes and how you can manage them. Identify all the pending check-in changes in one or more workspaces. You can also view the work items that are associated with the pending changes.
Check in pending changes: After you have reviewed your pending changes, you can check in those changes. As part of the check-in process, you can associate check-in notes or work items with the changeset. If your changes do not meet the check-in policies that are defined for the team project, you can override the check-in policy. You should override a check-in policy only after careful consideration. Check-in policies exist to protect the quality, stability, and performance of your application.
Resolve unwanted or incorrect changes: You might determine that one or more pending changes are not needed. You can undo those pending changes.
If you have already checked in changes that are unwanted or incorrect, you cannot roll back those changes by using Team Explorer Everywhere 2010. You must use the command-line client for Visual Studio to perform a rollback operation.
The following table explains the types of pending changes that you can check in.
Files that you add to Team Foundation version control are treated as pending add changes.
When you check out a file to modify in your workspace, Team Foundation makes it writable and adds an edit change to the list of pending changes for the workspace.
When you merge changes made in different branches, a merge change is added to the list of pending changes for the workspace.
The command-line client for Visual Studio can be used to run the tf rollback command to eliminate the effect of one or more changesets on an item.
You cannot use the rollback command from the Cross-platform Command-Line Client for Team Foundation Server.
When you run the command, rollback is added to the pending changes. For more information, see Rollback Command (Team Foundation Version Control)
When you delete a file in Team Foundation version control, it stays on the server until the delete is checked in. For more information, see Move, Rename, and Delete Version-Controlled Files and Folders (Team Explorer Everywhere).
When you undelete a file, after you check in the undelete change, the file is restored from the server during the check-in process. For more information, see Undelete Command.
Rename (includes file moves)
When you rename or move a file, it is renamed or moved on the local disk, but the changes are not reflected on the server until you check in the rename change. For more information, see Move, Rename, and Delete Version-Controlled Files and Folders (Team Explorer Everywhere).
When you branch a branch, the change takes place immediately on the server; no pending change is generated. However, when you branch a folder, the branch operation is not committed until the branch change is checked in.
For more information, see Branching Files and Folders (Team Explorer Everywhere).
If, during a branch operation, you convert the source and target folders to branches, that change is committed directly and does not need to be checked in. If a folder is converted to a branch, you cannot use Team Explorer Everywhere to convert it back to a folder.
When you change the file encoding of a file, the operation is not committed until the type change is checked in.