Understanding the Check-out and Check-in Concepts in Source Control Systems

The concepts of check-out and check-in mean different things in different source control systems. This can be confusing. In Microsoft Corporation"s Visual Source Safe (VSS) and Serena Software"s Polytron Version Control System (PVCS), check-out means "get the latest version of the file and lock the server version so that no-one else can edit it." In CVS and Subversion, check-out means "get the latest version", but without locking the server version. Other source control systems have different behaviors.

For Team Foundation Server source control, check-out means "Tell the server I want to edit this file and mark that file as writeable in my file system". While performing the check-out, users can also set one of three lock types for the server version: none, check-out, and check-in.

Users familiar with other source control systems may wonder why Team Foundation Server does not automatically get the latest version in response to a check-out command or does not perform an automatic lock. This behavior is carefully designed to match current developer collaboration practices and to maximize productivity, safety, and flexibility. It is made possible by the unique architecture of Team Foundation Server.

The last shall be first

The central concept in Team System is the TFS workspace. Each developer contributing to a Team project owns a TFS workspace with a unique name. A TFS workspace knows which local directories are mapped to which server directories and not only tracks your local pending changes, it tracks changes across all other TFS workspaces as well.

Anytime a file is checked in to a TFS workspace anywhere on the server, the source control repository is updated to reflect those changes and a new changeset is created. The last file checked-in to any TFS workspace across a team becomes the primary source control repository version; it will also be the first out of the repository when a Get Latest Version is issued. When you explicitly issue a Get Latest Version before check out, files in your TFS workspace (and local working folder) are updated to reflect the last modifications to that file. In some instances the server file will not differ from your local file; for example, if you were the last developer to issue a check-in to your TFS workspace. However, since you can't be sure another user didn't issue a check-in after you, a Get Latest is the only way to ensure you are working off the primary repository version.

Note: You may however set your preferences to always Get the Latest Version whenever you check a file out of your TFS workspace.

In the examples below red line numbers 1, 2, 3, etc. refer to versions (changesets) in TFS source control. Blue line numbers refer to workspace versions.

When you check out a file in source control, what you are actually doing is saying "Server, I am about to edit this file in my workspace." Your local file is then made writeable and the copy in your TFS workspace is placed in a pending state.

Depending on whether or not you have issued a Get Latest since the last updates to the server file, that file in your workspace may or may not be the latest version in the TFS Repository. When you check the file in, you take the file from your local working folder and commit it to the server. This now becomes the latest server version of that file.

Suppose, however, you did not do a Get Latest before you did the check out. Now when you go to check the file in, the server knows that your changes were based on an earlier version of the file so it will warn you that there are conflicts and prompt you to resolve these conflicts before completing the check-in.

Why does Team System not just get the latest version when you do a check-out on the file? The problem is that doing so might introduce new dependencies on files you don't yet have. Team System plays it safe and only gets a file when you tell it to.

Teamprise supports the Eclipse Synchronize view which gives you a summary of differences between your local workspace and the server so that you can see whether a change (i.e. a check-in) you are about to commit will cause any problems with the version that now exists on the server.

More about locking at check-out

Users may also wonder why there is not an automatic lock on every check-out, as in VSS (but not in CVS, Subversion, or Team System). This is to allow developers to check out a section of the source tree without blocking other developers from working on files in that section.

If required, you can configure a team project to force locking when checking out files; this has to be performed by an administrator of the Team Foundation Server. Additionally, you can set a preference within Teamprise to automatically attempt to lock any files with a desired lock type on check-out. However, if your TFS administrator has configured your Team Project to force a lock when performing a check-out then this will override the preference configured in your Teamprise client.

Note: Binary files types (such as word documents or GIF images), are automatically locked on check-out as the server would not be able to resolve conflicts should two users edit the same file.

Team Foundation Server design supports flexibility, power, and precision. Most users will find that they can take best advantage of its functionality by making frequent incremental check-ins.