Teach Yourself Visual Studio® .NET 2003 in 21 Days [Electronic resources] نسخه متنی

Using the Integrated SourceSafe Tools in Visual Studio .NET

The backbone of what makes SourceSafe tick is the process of checking files in and out of the VSS database. When you're working in a project under source control, you're using it for any number of reasons. This could be as a backup to your solutions, as a way of keeping version history of files, or as a way to quickly undo changes to a file when something doesn't work as expected. None of these options is possible if you aren't maintaining a history of the changes to your files. For this reason, you must diligently check files in and out of SourceSafe as you need them.

To check a file out of SourceSafe so that you can use it, you can either right-click on the file in the Solution Explorer and select Check Out from the contextual menu, or you can simply attempt to modify the file and the automatic check-out process occurs. When you check out a file, you're prompted with the Check Out dialog shown in Figure 20.7.

In the Check Out dialog, you can select the files that you want to check out and enter notes as to why you're checking the file out. In this case, leave the defaults for this check out, which are the Form1.vb file and the solution files.

At this point, the file is available for you to modify. SourceSafe gives you access to a local copy of the file, and the original file remains in the SourceSafe database. A red check mark with an exclamation point is positioned next to the file name in the Solution Explorer, giving you an immediate indication that the file is checked out to you exclusively. Exclusively means that no one else can check out this file.

If you right-click on the form1.vb file in the Solution Explorer, you'll see the SourceSafe-specific options that are available to you. These include

• Check In




• Show Pending Checkins




• Undo Checkout




• Get Latest Version




• Compare Versions

We'll look at each of these options now, but not necessarily in the order of the menu options.

Showing Pending Checkins

If you select the Show Pending Checkins menu item, the Pending Checkins window opens. It's docked to the bottom of your IDE, as Figure 20.8 demonstrates.

From this window, you can view the files that you have checked out for this solution. You can check files back into the VSS database, add comments to the files, view the changes to the file since the last checkout, and undo the checkout all from the Pending Checkins window.

Undoing a Checkout

The Undo Checkout option, which is accessible from the right-click contextual menu in the Solution Explorer from the Pending Checkins windows, enables you to revert to the original checked out version of the file you're working on. If you select this option, you're prompted with the Undo Checkout dialog box shown in Figure 20.9.

After you click the OK button, the file is sent back to the VSS database. If you modified the file since the last checkout, you are prompted with a dialog for each file that has changed, giving you the option to overwrite the files in the VSS database, cancel the undo checkout, or selectively leave dependent files checked out. Figure 20.10 shows the prompt after I made some changes to the Form1.vb class file and attempted to undo the checkout.

The undo checkout option is very useful when you make a mistake. Because Visual Studio .NET saves all files before you can build an application, you're never working on unsaved files. If you've just checked out a file, made some changes, and realized that you screwed something up, you can revert to the good copy of the file in VSS by undoing the check out. This is a very good reason to be diligent about checking files back in when you have made changes to them.

Getting the Latest Version

After you've checked a file out or you still have a file checked in, you might want to retrieve the most current version of a file from the VSS database. The Get Latest Version menu option enables you to retrieve the most current version of checked-out and checked-in files from the current SourceSafe project.

One situation in which this would be useful is when you need to build an application that you've been working on. To make sure that you have the most current files, you should obtain the latest versions of the files from the VSS database before you build. Each time you open a project from SourceSafe, it retrieves the latest version, but most of us have projects open in Visual Studio .NET for hours or even days, so there might have been changes to files without your knowledge.

If the latest version of a file you're attempting to get is different in your solution from the version stored in VSS, you have the option of merging the files. At this point, VSS merges your changes with the file from the server. This might occur often in a team environment.

Comparing Versions of Files

The Compare Versions contextual menu item enables you to view the differences of your file compared to the last checked-in version in VSS. If you select the Compare Versions item, you're prompted with the Difference Options dialog box. This dialog enables you to choose the files to compare and the output format for the report. Figure 20.11 shows the Difference Options dialog box.

Based on the format option you selectVisual, SourceSafe, or Unixthe output report shows different data. Figure 20.12 shows the Visual report option that's displayed after clicking the Report button.

In Figure 20.12, the complete original file version and the checked-out version are displayed side by side. You can browse a line at a time to see the differences in the files. If you preview the SourceSafe or Unix Format options, only the lines that are different are displayed in the report.

Checking Files Back In

When you're done working with a file, you must check it back into SourceSafe so that the history is maintained and others have access to it. Selecting the Check In menu item prompts you with the Check In dialog shown in Figure 20.13.

After you check in a file, the local copy of your file is marked as read-only and the checked-in file is sent back to the SourceSafe database. In the database itself, only the changes from the last checked-out version, not the entire file, are stored.

At this point, all the files in your solution are back in the SourceSafe database.

Note

When checking files in, you must make a decision about what state a checked-in file should be left in. There are two scenarios when checking files in. The first scenario is that the file is completed, tested, and you're done with it. The second check-in option is that you want to maintain a strict history of the changes to your files in SourceSafe. When working as a single developer, that's okay; you pretty much know the state of your applications. If you're working with a team, other people might assume that because the file is checked in, it works and it will successfully compile in their application. If your company does a nightly build or a solution and your file isn't tested, the build will fail. So, use caution when checking files back into the VSS database.