Checking Out, Checking In, and Getting Working Copy

These three actions are the backbone of day-to-day Visual SourceSafe activity. You employ them in the following manner:

• You check a file out when you intend to make changes to the file. The Visual SourceSafe checkout process places a writable copy of the file in your Working Folder. Usually, no one else can check the file out until you check the file back in.
  
  You can check a file out in Visual SourceSafe Explorer by selecting the file in the Visual SourceSafe project and choosing SourceSafe, Check Out from the menu. If no one else has the file checked out, SourceSafe gives you the chance to make a comment, checks the files out to you, and changes the file's icon to show that it is checked out (see Figure 2.15).
  
  
  FIGURE 2.15. - The appearance of a checked-out file in SourceSafe Explorer.

• When you check the file in, Visual SourceSafe stores the changes that you have made to the Visual SourceSafe database.
  
  You check the file in by selecting it under the Visual SourceSafe project and choosing SourceSafe, Check In from the menu. A dialog box will give you a chance to make comments (see Figure 2.16). The dialog box also enables you to decide whether to keep the file checked out to your account and whether to remove the local copy of the file after you have checked it in.
  
  
  FIGURE 2.16 - Checking a file in.
  
  Visual SourceSafe also changes the permissions on the copy of the file in your Working Folder to read-only
  
  When you check the file in, you also have the option of keeping the file checked out, as just mentioned. This has the effect of refreshing Visual SourceSafe's copy of the file, but keeping it checked out to you. In this case, the copy in your Working Folder remains writable.
  
  On the other side of the coin, you also have the option of checking the file in and then removing the local copy that you were working on (also just mentioned). In this way, the most recent version of the file is only stored in the Visual SourceSafe database.

• If you choose Get Working File rather than Check Out, Visual SourceSafe places a read-only copy of the file in your Working Folder.

When developers are working together on a multifile project, the development cycle with Visual SourceSafe goes through something like the following steps:

1. You use Get Working Copy to place the most current copies of all files needed to compile the project on your local system.

2. You check out the file or files that you personally will modify.

3. Because you have copies of all the project's files (some readable from step 1, and some writable from step 2), you can always compile the whole project to test the changes that you are making to the files that you are responsible for.

4. When it is time to compile and test the entire project, you and the other developers can check in all your files (making sure, of course, that the versions you check in run with the rest of the project).

5. If you need to, you can keep your files checked out to continue working.

6. You can also periodically refresh your local read-only copies of the files that other developers are working on. Just run the Get Working Copy action on the files that you don't have checked out.

• Creating a New Project Folder in Visual SourceSafe
• Adding Files to a Visual SourceSafe Project
• Setting the Working Folder for a Project
• Checking Out, Checking In, and Getting Working Copy
• Source-Code Labeling and Version Numbers
• Source-Code Sharing
• Source-Code Branching
• Pinning an Earlier Version of a File for Use in the Current Version of a Project
• Merging Two Different Versions of a File