D.4 Checking In and Out

Once your solution is in source control, you will not be allowed to modify it in any way without first checking out items you wish to change. This is to make sure that multiple developers don't work on the same file at the same time—a file can be checked out by only one developer at a time.

You can check an item out by selecting it in the Solution Explorer and then selecting File Source Control Check Out Filename. (The File menu will display the name of the selected file.) Alternatively, you can right-click on the file in Solution Explorer and select the Check Out... option from the context menu. Finally, if you attempt to modify a file that is not checked out (e.g., by typing in a source file or by changing a project's settings), VS.NET will offer to check the file out for you. (Of course, if some other developer has the file checked out, you will not be allowed to check it out until he checks it back in.)

Whichever of the mechanisms you use for checking out a file (or files, since you can check out multiple items at the same time), you will be shown the Check Out dialog, which is shown in Figure D-4. The Comments section allows you to specify the reason for checking the file out—this will be visible in the VSS browser, so you can let other users know why you have locked the file.

Figure D-4. Check Out dialog box

When this dialog appears as a result of attempting to edit a file that is not checked out, in place of the Cancel button you will find an Edit button. If you click Edit, VS.NET will allow you to modify the file without checking it out, although it will warn you that this is likely to lead to loss of data. This can sometimes be useful for performing an experimental change without having to check the file out. But be aware that such changes are transient—the source control database contains the master copy, and any changes made outside of source control are liable to be overwritten whenever you update your local copy of the project.

Once you have made the changes you require, you will want to push those changes back to the source control database—VS.NET always edits local copies of files, and you need to tell it when to write those copies back. This process is known as checking in, and it is done in much the same way as checking out—select the file or files in the Solution Explorer and select Check In, either from the File Source Control menu or from the Solution Explorer context menu.

D.4.1 Checking Out Versus Getting Latest Version

When you check out a file, VS.NET makes sure that your local copy is the most up-to-date version. So if the file has been changed by someone else recently, you may find that it looks different after you check it out—VS.NET has fetched a new version to make sure you are starting from the right place.

Checking a file out is not the only way of retrieving the latest version. If you right-click on a solution, project, or file in the Solution Explorer, you will find a Get Latest Version option. (For projects or solutions, this will usually have the text "(recursive)" appended, which indicates that it will retrieve the latest versions of everything in the solution and project, as opposed to just the .sln or project file.) This consults the source control database to see if any of the files have been modified by other developers, and if so, it copies the new versions to your system.

In a group project, you should get the latest version of any files in a solution you are working on regularly to make sure that your local copy of the project doesn't drift too far from the copy in the source control database. For the same reason, you should also regularly check in any files that you have checked out.

D.4.2 Check In Frequently

As a general rule, you should check in early and often. Automated builds typically work by retrieving the most recent version of the project from source control and building that. Changes you make to files will not be available in source control until you check those changes in, so your code will not become part of a nightly build until you check it in.

When multiple developers are involved, if files are not checked in regularly, the local copies of the project on the various developers' machines can become radically different—developer A may be writing code that works in conjunction with some class that is in the process of being modified by developer B. When they both eventually check their changes back in, the project may fail to work. These integration niggles are irritating, but in isolation they are usually fairly easy to fix. However, if you leave it for days or even weeks between checking files in, you are likely to have a huge integration mess to sort out before anything will work. If all the developers make a habit of trying not to go longer than a day or two between synchronizing their local copies with the database, these problems don't have the opportunity to grow.

Moreover, if you have a file checked out, nobody else can work with it. If you keep files checked out for long periods of time, you may end up holding other developers up. (Although if you really do have to work on a particular file for an extended period, it is usually best to check it in and back out every time you complete some meaningful unit of work, just to make sure that the copy in the source control database is kept up-to-date.)

Also, any sane development team will make sure that the server that contains the source control database is backed up on a regular basis (usually daily). However, it's not uncommon for developer machines not to be backed up at all. So checking in regularly reduces the potential for data loss.

For all these reasons, you should aim to keep as few files checked out as possible and to check files in as soon as you can.