7.2. Accessing Source Control

This section walks through the process of adding a solution to a new Visual SourceSafe 2008 repository, although the same principles apply regardless of the repository chosen. This process can be applied to any new or existing solution that is not already under source control. We also assume here that SourceSafe is not only installed, but that it has been selected as the source control repository within Visual Studio 2008.

7.2.1. Creating the Repository

The first step in placing a solution under source control is to create a repository in which to store the data. It is possible to place any number of solutions in the same repository, although this means that it is much harder to separate information pertaining to different projects. Furthermore, if a repository is corrupted, it may affect all solutions contained within that repository.

To begin the process of adding a solution to source control, navigate to the File menu and select Source Control Add Solution to Source Control, as shown in Figure 7-3.

Figure 7.3. Figure 7-3

If this is the first time you have accessed SourceSafe, this will open a dialog box that lists the available databases, which at this stage will be empty. Clicking the Add button will initiate the Add SourceSafe Database Wizard, which will step you through either referencing an existing database, perhaps on a server or elsewhere on your hard disk, or creating a new database.

To create a new SourceSafe database you need to specify a location for the database and a name. You must also specify the type of locking that is used when checking files in and out. Selecting the Lock-Modify-Unlock model allows only a single developer to check out a file at any point in time. This prevents two people from making changes to the same file at the same time, which makes the check-in process very simple. However, this model can often lead to frustration if multiple developers need to adjust the same resource. Project files are a common example of a resource that multiple developers may need to be able to access at the same time. In order to add or remove files from a project, this file must be checked out. Unless developers are diligent about checking the project file back in after they add a new file, this can significantly slow down a team.

An alternative model, Copy-Modify-Merge, allows multiple developers to check out the same file. Of course, when they are ready to check the file back in, there must be a process of reconciliation to ensure that their changes do not overwrite any changes made by another developer. Merging changes can be a difficult process and can easily result in loss of changes or a final code set that neither compiles nor runs. This model offers the luxury of allowing concurrent access to files, but suffers from the operational overhead during check in.

7.2.2. Adding the Solution

Once a SourceSafe repository has been created, the Add to SourceSafe dialog will appear, which prompts you for a location for your application and a name to give it in the repository. SourceSafe works very similarly to a network file share — it creates folders under the root ($/) into which it places the files under source control.

Although it is no longer required with SourceSafe, many development teams align the SourceSafe folder structure to the directory structure on your computer. This is still considered a recommended practice because it encourages the use of good directory and folder structures.

After specifying a name and location in the repository, SourceSafe will proceed to add each file belonging to the solution into the source control repository. This initiates the process of tracking changes for these files.

The Source Code Control (SCC) API assumes that the .sln solution file is located in the same folder or a direct parent folder to the project files. If you place the .sln solution file in a different folder hierarchy to the project files, then you should expect some "interesting" source control maintenance issues.

7.2.3. Solution Explorer

The first difference that you will see after adding your solution to source control is that Visual Studio 2008 adjusts the icons within the Solution Explorer to indicate their source control status. Figure 7-4 illustrates three file states. When the solution is initially added to the source control repository, the files all appear with a little padlock icon next to the file type icon. This indicates that the file has been checked in and is not currently checked out by anyone. For example, the Solution file and Form1.vb have this icon.

Figure 7.4. Figure 7-4

Once a solution is under source control, all changes are recorded, including the addition and removal of files. Figure 7-4 illustrates the addition of Form2.vb to the solution. The plus sign next to Form2.vb indicates that this is a new file. The tick next to the WindowsApplication1 project signifies that the file is currently checked out. In the scenario where two people have the same file checked out, this will be indicated with a double tick next to the appropriate item.

7.2.4. Checking In and Out

Files can be checked in and out using the right-click shortcut menu associated with an item in the Solution Explorer. When a solution is under source control, this menu expands to include the items shown on the left in Figure 7-5.

Figure 7.5. Figure 7-5

Before a file can be edited, it must be checked out. This can be done using the Check Out for Edit menu item. Once a file is checked out, the shortcut menu expands to include additional options, including Check In, View Pending Checkins, Undo Checkout, and more, as shown on the right in Figure 7-5.

7.2.5. Pending Changes

In a large application it can often be difficult to see at a glance which files have been checked out for editing, or recently added or removed from a project. The Pending Checkins window, shown in Figure 7-6, is very useful for seeing which files are waiting to be checked into the repository. It also provides a space into which a comment can be added. This comment is attached to the files when they are checked into the repository so that the reason for the change(s) can be reviewed at a later date.

Figure 7.6. Figure 7-6

To check a file back in, you should ensure that there is a check against the file in the list, add an appropriate comment in the space provided, and then select the Check In button. Depending on the options you have specified, you may also receive a confirmation dialog prior to the item's being checked in.

One option that many developers prefer is to set Visual Studio to automatically check a file out when it is edited. This saves the often unnecessary step of having to check the file out before editing. However, it can result in files being checked out prematurely, for example if a developer accidentally makes a change in the wrong file. Alternatively, a developer may decide that changes made previously are no longer required and wish to revert to what is contained in the repository. The last button on the toolbar contained within the Pending Checkins window is an Undo Checkout button. This will retrieve the current version from the repository, in the process overwriting the local changes that were made by the developer. This option is also available via the right-click shortcut menu.

Before checking a file into the repository, it is a good idea for someone to review any changes that have been made. In fact, some organizations have a policy requiring that all changes be reviewed before being checked in. Selecting the Compare Versions menu item brings up an interface that highlights any differences between two versions of a file. Figure 7-7 shows that a Form Load event handler has been added to Form1.vb. Although not evident in Figure 7-7, the type of change is also color coded; additions are highlighted in green text, while red and blue lines indicate deleted and changed lines.

Figure 7.7. Figure 7-7

Because source files can often get quite large, this window provides some basic navigation shortcuts. The Find option can be used to locate particular strings. Bookmarks can be placed to ease navigation forward and backward within a file. The most useful shortcuts are the Next and Previous difference buttons. These enable the developer to navigate through the differences without having to manually scroll up and down the file.

7.2.6. Merging Changes

Occasionally, changes might be made to the same file by multiple developers. In some cases these changes can be automatically resolved if they are unrelated, such as the addition of a method to an existing class. However, when changes are made to the same portion of the file, there needs to be a process by which the changes can be mediated to determine the correct code.

Figure 7-8 illustrates the Merge dialog that is presented to developers when they attempt to check in a file that has been modified by another developer. The top half of the dialog shows the two versions of the file that are in conflict. Each pane indicates where that file differs from the original file that the developer checked out, which appears in the lower half of the screen. In this case, both versions had a message box inserted, and it is up to the developer to determine which of the messages is correct.

Unlike the Compare Versions dialog, the Merge dialog has been designed to facilitate developer interaction. From the top panes, changes made in either version can be accepted or rejected by simply clicking the change. The highlighting changes to indicate that a change has been accepted, and that piece of code is inserted into the appropriate place in the code presented in the lower pane. The lower pane also allows the developer to enter code, although it does not support IntelliSense or error detection.

Figure 7.8. Figure 7-8

Once the conflicts have been resolved, clicking the OK button will save the changes to your local file. The merged version can then be checked into the repository.

7.2.7. History

Any time a file is checked in and out of the SourceSafe repository, a history is recorded of each version of the file. Use the View History option on the right-click shortcut menu from the Solution Explorer to review this history. Figure 7-9 shows a brief history of a file that had three revisions checked in. This dialog enables developers to view previous versions, look at details (such as the comments), get the particular version (overwriting the current file), and check out the file. Additional functionality is provided to compare different versions of the file, pin a particular version, roll the file back to a previous version (which will erase newer versions), and report on the version history.

Figure 7.9. Figure 7-9

7.2.8. Pinning

The History window (refer to Figure 7-9) can be used to pin a version of the file. Pinning a version of a file makes that version the current version. When a developer gets the current source code from the repository, the pinned version is returned. Pinning a version of a file also prevents anyone from checking that file out. This can be useful if changes that have been checked are incomplete or are causing errors in the application. A previous version of the file can be pinned to ensure that other developers can continue to work while the problem is resolved.