Source Control in the Designer (BIDS)

One of my first experiences with source control was at a small startup company where our "source control" was a whiteboard. To check out a file, you put a check mark next to the name of the file. Nobody else was allowed to modify the file if it was "checked out." What a mess! Human error reigned supreme and we were always having problems with our code base because of it. Thankfully, the Business Intelligence Development Studio provides integrated support for source control so you don't have to revert to such schemes for controlling your Business Intelligence solutions. Any source control provider that supports the SCCAPI protocol, such as Visual SourceSafe, Clearcase, Visual Studio Team System, PVCS, or QVCS, will integrate with Visual Studio, making it possible to seamlessly add new solutions, projects, and files to your source control repository inside the designer environment. The Solution Explorer gives visual indications as to the source control status of files and even provides views of the pending changes. Essentially, in addition to being a package or cube designer, the Visual Studio environment becomes the source control management interface as well. The Visual Studio source control features are too numerous and rich to fully document here. So, although this chapter can't cover all the details, it does try to cover the most useful, difficult, and problematic elements.

Setting Up

Before you can set up source control in the designer, you need to have a source control provider installed. This chapter demonstrates the provider Visual SourceSafe. After you have the source control provider installed, you can turn on source control in the designer by selecting the main Tools menu and clicking the Options menu option. The Options dialog box opens, as shown in Figure 16.1.

Figure 16.1. The Options dialog box with the default source control settings

The Plug-in Selection tab lets you select which source control provider you want to use. The sample has Visual SourceSafe selected. The Environment tab, shown in Figure 16.1, mainly controls the timing of when projects and files get checked out and checked in. Depending on how you like to work, you can change these settings. The Environment tab shows settings that are universal across source control providers.

Caution

Some of these settings are questionable. For example, checking in everything automatically seems dubious. Generally, checkins should be explicit, not implicit. In other words, you should only check in when you intend to check in and then you should be careful and intentional about how you do the checkin. With this setting, and the Don't Show Check In Dialog Box when Checking In Items setting, you could easily forget that files are actually being checked in when closing down a solution and check in code or packages that are broken. It's easy to see how this could become a problem in some environments where central IT departments upgrade machines with the latest virus signature files and reboot the machines automatically. If you ever happen to leave a package partially edited and BIDS shuts down, closing and checking in the solution in this way, you might "break the build" because of your partially edited package or code.

You should also be careful with the Get Everything when Opening a Solution setting. It is generally considered bad form to check out entire projects with all the project files unless you plan to edit each of them simultaneously. This is especially true when working on large teams where you increase the chance of causing a merge resolution or you block them from checking out a file. As a rule, you should only check out files for as long as you need them and no longer. It's similar to the old development wisdom that you should "free all resources as soon as possible, but no sooner."

To see settings that are specific to the source control provider, select the Plug-in Settings tab, and then click the Advanced button; the SourceSafe Options dialog box opens, as shown in Figure 16.2.

Figure 16.2. SourceSafe Options

These settings are covered well in the SourceSafe documentation, so they aren't all explained here. However, you should know where to find these settings in BIDS.

After you've enabled source control, you still need to add solutions to the source control repository. You can add both new and existing solutions. To add an existing solution, right-click on the project or solution node in the Solution Explorer. The context menu shown in Figure 16.3 appears.

Figure 16.3. Adding solutions to source control

If you haven't already logged in to the source control system, a login dialog box opens. After logging in, the Add to SourceSafe Project dialog box opens, as shown in Figure 16.4.

Figure 16.4. The Add to SourceSafe Project dialog box

You can create a subfolder here for the solution or add it to an existing folder. Practices for how to structure your source abound, so this chapter doesn't cover that topic. However, it is good to have a dedicated folder for a solution because BIDS manages source control at the solution level.

Figure 16.5 shows the New Project dialog box with the option to add the project to source control.

Figure 16.5. Adding a new solution to source control

Using Source Control

After you've set up source control in the Visual Studio environment and then added a solution, a number of changes become available in the designer to enable you to easily work with source control:

• A new Source Control menu appears on the main File menu.

• Small icons appear next to the Solution Explorer nodes.

• A new source control menu section appears on the Solution Explorer context menu.

• The Source Control toolbar is enabled.

Source Control Menu

The Source Control menu has only two menu options when you have no solution loaded. The first is Open from Source Control. This option does a get on a solution. You only want to do this if you don't already have a solution on your local machine. After you've sync'ed to the solution in this way, you should open the solution as usual, with the File, Open Solution menu option. The second option is to open the Visual SourceSafe environment. This is usually not necessary unless you need to label, merge, or move files.

The File Source Control menu changes depending on what object you have currently selected. For example, if you have a package open in the designer and you've clicked on the drawing surface, the menu options such as Get, Check Out, and History will act on the selected file. With the solution open, and the YUKONB3.dsv file selected in the Solution Explorer, the Source Control menu looks similar to the one shown in Figure 16.6.

Figure 16.6. The Source Control menu allows you to perform the most common operations

Get the Latest Version

The first menu option is to get the latest version of the file that is currently open in the designer. In this case, it is the YUKONB3 Data Source View. If you have the file checked out, and you select this option, the Microsoft Visual SourceSafe dialog box shown in Figure 16.7 opens, giving you several options from which to choose.

Figure 16.7. Options for syncing to a file you have checked out

The Replace option replaces the local file with the one from source safe, overwriting any changes you may have made. This is useful if you've made changes to the file and want to back up to the currently checked-in file. This is essentially a big undo. If you regularly check in your functioning package or other file, you'll always be able to revert to the last known good state or recover most of your work should you accidentally or catastrophically lose the file.

Use the Merge option when you want to "pick up" the changes others have made. However, it is not recommended to use this option when working with packages.

Caution

If you choose to use the Merge option, back up the package first. Packages are not like your average source code that can be compared on a line-by-line basis. There are internal references to other objects within the package. A simple merge can corrupt packages and even make them unusable. Be very careful with this option.

The Leave option simply leaves the local file undisturbed.

Check Out and Check In

These menu options provide a way to check in or check out the source file. When you check out a file, it also performs a sync. In other words, the existing local file will be overwritten with the current version of the file found in the source repository and marked as writable on the local system.

Undo Check Out

This is the "Oops, I really didn't need to check out that file" option. Or, you might want to use this option when you've made edits that you don't want. Either way, when you choose this option you lose your edits to the file permanently. Be careful with this option.

View History

View History lets you view the details of all the checkins for a given file. When you select this option, the History Options dialog box shown in Figure 16.8 opens.

Figure 16.8. The History Options dialog box filters the history items to view

As you can see, this dialog box allows you to filter the history by date and user. To view all history items, leave the From, To, and User fields empty. Click the OK button and the History dialog box shown in Figure 16.9 opens.

Figure 16.9. The History dialog box shows filtered history entries for a file

From Figure 16.9, you can see that the file has been checked in three times and the dates it was checked in and created. You can also perform other operations such as getting an older file by selecting the version entry in the list and clicking the Get button. If you select two version entries in the list and click Diff, a diff utility graphically shows the differences between the two files. The files do not need to be chronologically adjacent to each other. Figure 16.10 shows the Difference Options dialog box that opens when you click the Diff button.

Figure 16.10. Select settings for the files to diff

Various options for the type of diff you want to perform are available, as well as for browsing for different files or creating a report. After you've selected the settings you want, click the OK button and the graphical difference viewer shown in Figure 16.11 opens.

Figure 16.11. The graphical difference viewer makes it easy to spot file differences

The difference viewer highlights lines that have changed. Some lines might have only a single character difference. Others might be new or deleted. It's a good practice to do a difference on every file before checking it in, right before checking it in.

Checking In

On one project, I was just about ready to check in some code. I had performed the code review, done the diff on the files, and was ready to do the checkin. However, I had put off nature for a few hours too long and really needed to see a man about a dog. So, I scuttled off to take care of business and quickly returned, promptly checking in the code. An hour or so later, I received an email that was broadcast to the whole team that said I had broken the build. The error that caused the break was promptly displayed in the email with the embedded string "Kirk is a dork." I was very embarrassed, of course. What happened was, one of my co-workers thought he'd leave me a friendly note in my editor. I did two things wrong, wait, no, three. I didn't lock my machine when I left, I didn't double-check the diffs, and I waited far too long to take care of nature.

Solution Explorer Changes

Figure 16.12 shows the Solution Explorer with source control enabled.

Figure 16.12. The Solution Explorer contains visual hints as to file check-in status

There are primarily three icons that appear:

• The Lock The file is checked in.

• The Check The file is checked out.

• The Plus The file is new and hasn't been added to source control yet.

Source Control Menu Section in the Solution Explorer Context Menu

Most of the same options are found here as on the main File menu. However, the View Pending Checkins menu option is only found on this menu. Select this option and the Pending Checkins dockable window opens, as shown in Figure 16.13.

Figure 16.13. The Pending Checkins window shows potential solution changes

The Pending Checkins window makes it easy to see what files are checked out. You can also directly check files in with comments using this window.

The Source Control Toolbar Is Enabled

Finally, the Source Control toolbar is another way to access the source control features. All toolbar operations act on the currently selected file in the Solution Explorer.

As you can see, you can interact with the source control system in Visual Studio in many different ways. This seamless integration really makes source control a breeze and enhances the overall development experience.