Inside Microsoft® Visual Studio® .NET 2003 [Electronic resources] نسخه متنی

Source Control with Visual SourceSafe

Visual Studio .NET ships with support for VSS, and the Enterprise Developer and Enterprise Architect editions of Visual Studio .NET ship with the bits required to set up a VSS server.

In this section, we'll talk about getting up and running with a VSS server and how you can put your projects under source control for versioning and protection and to help manage team development.

Setting Up VSS

Even if you're a single developer, you should try to set up a VSS server on a machine separate from your workstation. That way, even if your workstation hard drive dies, you have a fairly recent version of your project under source control on another server.

Placing Files Under Source Control

To use VSS with Visual Studio .NET, you should set up the version of VSS that ships with Visual Studio .NET. Here we'll assume that you've set up your VSS database properly and that you want to access that database using the tools built into Visual Studio .NET 2003.

When you first run Visual Studio .NET on a workstation, you'll notice that the Source Control menu items are grayed out. To take advantage of the VSS features built into Visual Studio .NET, you must first install the VSS client on the workstation. You can usually install the client from the share containing the server. Look for the file Netsetup.exe in the shared VSS folder on the server. Run this file to install the client.

You can use the VSS client to do your initial setup with VSS. First open the VSS database that you'll be using to maintain your code. After installing the VSS client, you'll find a link to the executable in the Microsoft Visual SourceSafe folder on the Start menu. Open the client and press Ctrl+P to display the Open SourceSafe Database dialog box. Browse to your VSS database share and open the srcsafe.ini file there. Figure 15-4 shows how this dialog box looks after you specify the appropriate file.

When prompted, enter the username and password that you or your administrator have set up, and you should be in business. Figure 14-5 shows a VSS database set up to help manage the code and chapters written for this book. At this point, you can close the VSS client application. From here, we'll do most our work in Visual Studio .NET.

Once your database is set up and you have access from your workstation, you can start putting solutions and projects under source control. First open a solution in the IDE or create a new solution. On the Visual Studio .NET File menu, choose Source Control and then choose Add Solution To Source Control, as shown in Figure 15-6.

You'll see the Visual SourceSafe Login dialog box, followed by the Add To SourceSafe Project dialog box (shown in Figure 15-7), which lets you select or create a folder for the project.

Placing a solution under source control results in the solution being added to the VSS server. The solution you started with is now considered a working copy, and you must check out the files from VSS to make changes. You can see the Solution Explorer window for a project under source control in Figure 15-8. The lock icons in Solution Explorer indicate that the files are copied locally but aren't checked out for editing. A checked out file has a check mark next to its name.

Working with Files Under Source Control

Once you place a solution under source control, you and your team members can access the solution through Visual Studio .NET. On the machine where the initial solution was created, the files added to VSS become the working copy for that particular developer. Alternatively, you can delete the local folder and open the VSS version of the solution, copying it to a new location on the workstation.

To open a project from a VSS server, from the File menu choose Source Control and then choose Open From Source Control, or enter File.OpenFromSourceControl in the Command Window. This opens a Visual SourceSafe Login dialog box, where you can enter your credentials and select the VSS database you want to access. After logging in, you're presented with a Create Local Project From SourceSafe dialog box like the one shown in Figure 15-9.

Select a project and click OK, and you'll see a Browse Folder dialog box that lets you select the working folder for the solution. The program adds the folder you select to the Create A New Project In The Folder box. Click OK a second time to copy the solution files to your local machine and display the Open Solution dialog box, which contains the .sln file for your solution. Select the .sln file from this dialog box, and you'll be working with the local copy of the solution.

Note

You can set a network share as your working folder for the solution. With VSS, it's often easiest to map a network share to a drive letter and use that when you work with older-style common dialog boxes.

Working with files under source control is fairly straightforward. When you begin to edit a file, you lock that file on the server so no other developer can make changes at the same time. This is the "control" in source control.

Let's look at what happens when two developers work on a single solution using source control. Both developers have the solution open through VSS to a local folder or network share and are working on these projects in Visual Studio .NET. Let's say Marc is in the process of adding a button to a dialog box. When he attempts to make a change to the file, a Check Out For Edit dialog box (shown in Figure 15-10) appears and gives him the opportunity to add a note about what he's doing before checking out the file.

Keep in mind that both developers are working in Visual Studio .NET the whole time and are prompted to check out files as they work. Almost everything about working with VSS databases in Visual Studio .NET is automatic, so you don't have to go hunting for files using the VSS client.

At this point, Brian wants to make a change to the form that Marc has checked out. Marc hasn't checked in his changes yet, and he still has exclusive access to the files. This means Brian can't make a change until that file is checked in. When Brian tries to check out this file for editing, he's prompted with the cancellation dialog box shown in Figure 15-11.

If Brian really needs this file, he can ask Marc to check it in. Small teams can work informally in this way, but with larger teams, you most likely won't touch each other's code. As you can see, though, the source control features make it clear who has control of the source file at any given moment and that changes aren't permitted on that file until the person who has control of that file checks it back into the database.

Let's say Marc has made his changes to the file and is ready to check the changes back in. He can check the files in by right-clicking on the checked out files in Solution Explorer and choosing Check In from the shortcut menu. This opens the Check In dialog box shown in Figure 15-12. Here, he can enter a comment about the files that he's checking in. This comment can be directed to the program manager or to other developers on the project.

At this point, Brian is working with an out-of-date copy of the source files. What happens if he tries to edit the old form on his machine? The answer is that when VSS checks out the file for editing, it replaces the outdated version of the file on Brian's machine with the updated file from the database.

To update the files on a local machine to the latest available in the database, you use the File.GetLatestVersion command. This command is also available from the shortcut menu in Solution Explorer. If you've made changes to a file that you've checked out, you can either merge those changes back into the database or you can keep working without merging your changes back in. In either case, changes checked in by other developers are applied to the source files in your solution.

A couple of VSS features that are available from within Visual Studio .NET are worth noting. The first is the History command (File.History). This command works on a file-by-file basis; you access it from the Source Control submenu of the File menu or from the Command Window. The History command opens a dialog box (shown in Figure 15-13) that lists who has checked out a file and when. You can double-click on any of the versions listed to display the History Details dialog box shown in Figure 15-14, which contains any notes that were added when the file was checked in.

Another interesting feature is the Pending Checkins tool window (shown in Figure 15-15). This dockable window is available only when you have files currently checked out. You can access this dialog box through the Source Control submenu of the File menu or through the shortcut menu in Solution Explorer. This tool window offers some features that aren't as easy to find in the other available dialog boxes. For example, you can click the Option button on the Pending Checkins toolbar to keep a file checked out while you check a version in. You can thus make changes available to others while ensuring that you keep control of the file.

Planning Your Solutions Carefully

When you work with more complex, multiproject solutions in VSS, it's important to plan your solutions carefully before checking them in for the first time. This planning can save you a lot of grief later on. The most important thing to remember before performing that initial check-in is to keep your main solution file in a parent folder that contains individual folders for each of the projects in your solution. For example, say you want to create a solution that contains three separate components. It has a GUI of some sort written in Visual Basic .NET. It has a class library written in Visual C#, and it has a COM component written in Visual C++. (We talked a bit about combining these types of projects in a single solution in Chapter 2.)

To combine all of these project types into a single solution, you should first create a folder to hold the solution. You can do this by creating an empty solution in some convenient location. From there, you should add new projects to the blank solution and place the folders for these projects in the same folder that contains the main solution file.

Once you have all your projects in place in your solution, you can check that solution into VSS, as described earlier in the chapter. Now it will be a little easier for VSS to maintain the links within your project, and it will be easier for developers assigned to the different components in the solution to maintain their own projects under source control.

Note

For those planning to do a lot of large-team development under VSS, Microsoft has an excellent document with a lot of great information about how to plan solutions, builds, and source control. The document is titled "Team Development with Visual Studio .NET and Visual SourceSafe" and is available on MSDN at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/tdlg_rm.asp.

Don't Break the Build

One of the most important things about source control is that it helps you perform regular builds so you can continually run and test the product. These kinds of builds should be performed as often as is reasonable given the size and scope of the overall project and the size of the project team. To that end, you should make sure that your new code builds before you add it to source control.

The idea behind source control is that you keep a good version of the product going all the time. If code that you check in to the VSS database breaks the build, it might interfere with the efforts of the other development teams working on components. You therefore shouldn't check in code until it's in a state where it can be compiled into the product without causing problems. Source control in a multideveloper scenario shouldn't be used as the backup repository for your ongoing work. Rather, you should back up the projects on your workstation nightly and check in code when it's ready to run.

Note

Of course, in a single-user scenario, VSS makes an excellent backup solution, and it's perfectly legitimate to work in that way.