Enterprise Source Control
with Microsoft Visual Studio 2005 Team System

Article by Peter Himschoot (peter@u2u.be)
U2U - Brussels (www.u2u.net)

Applies to

.NET Framework 2.0
Microsoft Visual Studio .NET 2005
Visual Studio Team System
Source Control

Summary

In this article we are going to focus on source configuration management (SCM) features of Visual Studio Team System (VSTS), and show what features are important for us developers in day to day development. We also compare some features to Visual Source Safe, and at the end of this article we’ve included a hands-on lab so you can try for yourself!

Introduction

Most developers on the windows platform learned source control using Visual Source Safe (VSS), and for those of you who are wondering: Visual Studio 2005 (VS2005) will still come with VSS. However, VSS was originally designed for small teams, so some features don’t work well when you start using VSS with more than (let’s say) 5 developers. Now with VSTS, large teams will be happy to hear that Team System Source Control is a complete new product, designed for large teams - easily handling 500 or more developers on the same team - and Microsoft is already using VSTS internally to develop VSTS. In the near future they even intend to use it for all development within Microsoft! VSTS has support for distributed development, allowing teams to work together - no matter where they are based on our little planet - in a safe and efficient way. So read on if you want to learn more about the new source control management features of VSTS.

Why Use Source Control?

Let’s start with the question why you would want to use source control. In teams with more than one developer, source control is essential. Just imagine you have a file called foo.cs; and because there are several developers in your team, you keep all sources on a shared drive. One day you start adding a big important function to foo.cs and after two days of hard work you copy your changes to this shared drive. But what you did not know is that another developer is also making changes to this same file, and he (or she) copies their changes to the shared drive too, actually overwriting your changes! Ouch! Source Control keeps track of who is editing each file, and makes sure nobody loses any changes by locking and/or merging files.

You would do that as follows:

First you get some version (typically the latest) of one or more files.
Some of these files you want to modify, so you checkout these. This way a source control system knows who is modifying what.
After making the changes you checkin the file to the repository with any additional notes talking about the changes.
Go to first bullet

What about when you’re a poor lonesome cowboy? Do you need source control? Again imagine you’re working on foo.cs and suddenly a new bug appears. Did this bug come from the latest change you made, or was it because of some update to the operating system? How can you know? What you really want is to run an older version of the program to see if the bug is also there. Well, source control also keeps track of the history of every file, allowing you to restore any version of foo.cs. This way it is easy to see if the bug is caused by changes to foo.cs, and since you can see the differences between versions, even track down the change causing the bug. We will see this is just the top of the advantage ice-berg of using SCM systems like VSTS!

Transactional checkin

So where are all your precious sources stored? VSS stores all items tracked by source control in a special directory format; and every item is checked in separately. This means that it is possible that when you check in two files with dependent changes – meaning that you need both of them to compile successfully – and one of the files has a problem during check-in, that your project will no longer compile. And any other developer synchronizing with the main source branch will suddenly get all kinds of compile errors!

VSTS stores all items in SQL Server 2005 tables and checkin is done inside a database transaction; meaning that either both files get checked in, or none. This is of course very important if you’re working with tens of developers on the same project!

Workspaces and ChangeSets

Ever tried to rename a file with VSS? Well, let’s just say it is possible but way too hard. In VSTS it is a piece of cake, just rename the file. What actually happens is that, until you checkin, the file is only renamed locally. Additionally, VSTS keeps track of the rename of the file in your local workspace. What is a workspace? Every project kept in source control under VSTS is associated with a workspace, which is a client-side copy of every item under source control. For example, when you create a new solution and project, Visual Studio automatically creates a workspace mapped to the local solution and project folder (figure 1).

Figure 1: Solution and Project Mapping

Every change to an item is kept in the workspace, such as when you edit or rename a file. Using the Pending Checkin window (figure 2) you can see these changes:

Figure 2: Pending Checkin

When you checkin, the workspace’s changes are grouped into a changeset and sent to the server. The server applies these changes to the repository. In this case the central version file is renamed. When the checkin was successful, other developers getting the latest changes receive your changeset (and possibly other changesets) containing the rename of the file, and their local copy is renamed. Clean and easy!

By the way, technically, a changeset is a version of the repository at a specific date and time; we will get back to this a little later on.

Work Items

VSTS is more than just a SCM system. In many projects you will find lists of bugs, lists of tasks, lists of … VSTS uses the work item system to keep track of lists. Work items represent tasks, bugs, or whatever you would like. VSTS allows you to define what a work item is, what fields a kind of work item should contain, where to place the fields, etc… Work items are completely customizable. Figure 3 is an example of a task work item, asking darren to add some functionality to method Foo. The details of the exact changes have been attached to the work item as a word document using the File Attachments tab. As a developer you should check work items assigned to you, and only perform changes to sources when asked in a work item. This way everyone on the project can see what needs to be done, what has been done, and detailed reports can be drawn from work items. Of course as a developer you could create your own work items, but testers and project managers will too. For example when a tester finds a bug, she creates a new bug work item and assigns it to a developer.

Figure 3: A Sample Task Work Item

Integrated Checkin

Version control is indispensable for team development, but when you integrate source control with change management and bug tracking systems, source control goes to a new level. To start, let’s assume bug tracking and source control are not integrated. One morning you get a new bug report and you start working on a fix. It is a complex fix so you work on it hard… Finally you fix the bug, and by then it is dark outside, and you’re tired and want to go home. You will probably forget to update the bug tracking system; possibly resulting in a loss of time for other team members waiting for this bug to become fixed. In VSTS, the bug tracking system (actually the work item system) is integrated with source control, so when you checkin your fix, you can associate the changeset automatically with the bug during checkin:

Figure 4: Associate Work Item to Checkin

As you can see from figure 4, you can either associate a work item, or you can have the work item automatically resolved (closed). This is quite handy when you checkin a bug fix. By resolving the bug during checkin you don’t need to go to a separate bug tracking system, and any tester can automatically be informed that she needs to check if the bug is actually resolved. Should she find a problem, she can create a new bug work item and link it to this one. This way you even get a trail of linked work items!

It also works in the other direction. For example, sometimes you need to know what you did to fix a bug a couple of months ago. Because the changeset is associated with the bug work item you simply go to the work item system, look for the bug work item, open the links tab (figure 5), retrieve the changeset to examine the changes (figure 6) and right-click any file to see the differences (figure 7).

Figure 5: Work Item Links

Figure 6: Change Set Details

Figure 7: Changes Made to MainForm in ChangeSet #5

Checkin Policy

Of course simply checking in files may not be enough. What if a team member checks in sources with syntax errors (can you say that you never forgot to recompile before checking in files)? VSS has no way to prevent this, but VSTS allows you to define checkin policies; validation rules used to restrict the kinds of changes developers can make and what kind of tools need to execute successfully for them to checkin. For example VSTS comes with a built in policy that the project needs to compile with no errors. You can enable this policy using the Create New Checkin Policy window as shown in figure 8:

Figure 8: Create New Checkin Policy

If you now try to checkin, and you didn’t compile successfully your project you will automatically get a policy warning. Another interesting policy is one that requires you to link to a work item before you can checkin. This is to encourage developers to do task-based development to keep changes to sources as small as possible and for one task only. This way it becomes easier to see what exactly was done, for example what you did to fix a nasty bug. The third policy that will ship with VSTS RTM is a policy that ensures your checkin tests pass, such as important unit-tests. If you enable every built in policy, developers can only checkin code that compiles, successfully passes code analysis, successfully passes unit testing and has been linked to a work item. Talk about quality assurance! And of course you can add your own policies to VSTS. For example you could add a policy so each source file has a copyright header at the top of the file.

VSTS simply encourages you to adhere to checkin policy; should some situation warrant checking in files that violate policy you can always override policy, supplying a good reason (see figure 9). Of course project managers will be notified that a policy was ignored, so they can investigate why. No policy violation should go undetected!

Figure 9: Policy Failure Dialog

Checking out files

VSTS supports a very large number of developers. Now in this case we have to consider how the SCM system is to lock files when a developer checks out a file. There are two main ways: single and multiple checkout.

Single-Checkout

VSS uses (by default) a single-checkout scheme, meaning that as soon as one developer checks out a file it is locked for other developers. This is essentially the same technique as pessimistic locking for databases. For example we have a file called foo.cs with two methods Foo and Foo2:

public void Foo()

{

...

}

public void Foo2( int i )

{

...

}

As soon as one developer makes a change to this file it becomes locked and other developers are blocked from making changes (they can still see the latest version). Clearly when there are a lot of files checked out, many developers will be waiting for some file to become unlocked (you unlock a file by checking it in). This is of course a waste of precious time, so we need to consider another technique.

Multiple-checkout

VSTS uses another locking mechanism called multiple-checkout (VSS also support this locking scheme by the way, and it works nicely). With this scheme, when a developer makes a change to a file it does not become locked for other developers; instead the system merges changes for each developer checking in (essentially similar to using optimistic locking for databases). This is because experience shows that in many cases developers work on other parts of the same file, and SCM systems can easily merge these changes automatically.

For example dev1 changes Foo:

public void Foo()

{

dev1 makes some changes

}

public void Foo2( int i )

{

...

}

And dev2 changes Foo2:

public void Foo()

{

...

}

public void Foo2( int i )

{

dev2 makes some changes

}

Now when dev1 and dev2 checkin their changes the system can automatically merge them no matter which developer checks in first.

public void Foo()

{

dev1 makes some changes

}

public void Foo2( int i )

{

dev2 makes some changes

}

In case two or more developers make a change to the same part of a file, some manual merging is required. Merging changes to the same part of a file is easy for developers especially when specialized merge utilities can be used. Care has to be taken though to make sure merging does not introduce compile errors.

For example dev1 changes Foo:

public void Foo()

{

dev1 makes some changes

}

public void Foo2( int i )

{

...

}

And dev2 also changes Foo:

public void Foo()

{

dev2 makes some changes

}

public void Foo2( int i )

{

...

}

The first developer checking in will have no problems, but the second developer will need to manually merge these changes:

public void Foo()

{

dev1 and dev2 their changes

}

public void Foo2( int i )

{

...

}

Figure 10 shows the default merge utility in action (actually the VSS merge-utility J). An important detail is that VSTS will not checkin files after a merge operation, because merging might still miss some compile errors. Normally, after a merge operation you should re-compile and re-test to see if everything is still working ok, then checkin files again.

Figure 10: Merging changes

Branching

In the part on checking out files we saw how developers can work in parallel on the same file, now let’s see how we can work on multiple versions of the same project in parallel. Let’s say you’ve just finished version 1.0 of your product, and it is selling real good, so you start building version 2.0. Of course you want to use version 1.0’s code base as a starting point; but you also need version 1.0’s original code to fix bugs that customers may find. We could simply copy the repository and work on two separate projects. But how about bugs found in one version? Wouldn’t it be nice to be able to migrate the bug fix from one version to the other (for example a bug found in version 1.0 will probably still be in version 2.0). We can’t simply copy the file itself to the other version because other changes might have been done to this file which would be overwritten. And manually retyping the bug fix is of course totally impractical!

So how can we solve this problem? Branching is the solution; a branch is where you have a separate copy of the project but with shared history for the files (VSTS actually does not physically copy the files, it uses a link instead). This way you can work on a branch without affecting any other branches. For our example we would have an original branch for version 1.0 and a separate branch for version 2.0, as in figure 11.

Figure 11: branches for our project

We can create a branch using the Source Control Explorer (SCE) window from Visual Studio 2005, right-clicking the solution folder and selecting Branch (see figure 12).

Figure 12: Branching using Source Control Explorer

Next you will have to choose a proper name for the new branch. VSTS by default appends branch, but you can pick whatever name you like.

Figure 13: Picking a name for the branch

As you can see from figure 13, you can select what version to branch, for example you can select a changeset as a version, a date, or a labeled version.

Figure 14: Source control after branching

However, VSTS will not branch directly (see figure 14); the branch is created in our local workspace, so we need to checkin to have the branch persisted. The easiest way to accomplish this is first loading the branched solution in Visual Studio by right-clicking the solution file and selecting View… from the context menu. Then you checkin (see figure 15).

Figure 15: Pending Checkin after branch

Merging

So after a while you’ve made several bug fixes to version 1.0 and you’d like to apply these changes to your intermediary version 2.0 too. Because we’ve branched from version 1.0 this actually becomes a piece of cake; we simple pick from version 1.0 the changesets we want to apply and merge them into version 2.0 (this is known as cherry-picking merging). This also works in the other direction, so for example when we’ve substantially changed a method in version 2.0 and we would like to use it in version 1.0 we can merge the changeset with the changes to version 1.0’s branch (see figure 16).

Figure 16: Merging branches

Let’s assume we have made a couple of changes to our new branch and we would like to merge these changes back to the original branch. We go to the SCE window, right click the branch whose changes we want to merge and select Merge from the drop-down menu. The Merge Wizard appears (figure 17):

Figure 17: The Merge Wizard

We select the destination branch, and because we only want to merge one changeset in this example we select the “Only selected changes in the source branch” option. The Next button allows us to select the changesets we want to merge and then we hit Finish. To complete the merge we have to go back to the original branch (use view from the original solution’s drop down menu in the Source Control Explorer), verify that the merge compiles and works correctly, and then we checkin.

Team System’s ability to have multiple branches and being able to merge changes from one branch to another is essential when working on multiple versions of the same product.

Shelving

Have you ever been working on a complex piece of code, and you know you are about to make a difficult and extensive modification to the sources of your project? To make things even more drastic, you’re not even sure if they are going to work. In this case, would it not be prudent to have a copy to fall back to, also called a checkpoint? However, you can’t check in because the code is still buggy, and it might not even compile. What to do? You actually want a safe place to store your changes without disrupting other developers with your code. Shelving is the answer.

Shelving allows you to take all the changes you’ve been making and put them in source control, but only for yourself (analogy: you put stuff on your shelf). This means that you can shelve whatever you want; nobody is going to see those changes until you check them in.

Let’s take another example. Again you’re working on a complex piece of code that doesn’t even compile, and your boss walks in with an urgent matter (a bug found by a customer who needs a fix) you need to do right away. You can’t check in because your code doesn’t compile, and of course you don’t want to lose your changes (you’ve been working for several days on the code now). What to do? Again you can save all your changes on your shelve, rollback to the main source, fix the bug, check in the bug fix, and unshelve your changes to continue working. This is known as interrupted development because you have to drop whatever you’re doing, do something else and then continue from where you left off.

So how does shelving work? The Pending Checkin window includes a Shelve button (see figure 18) that allows you to shelve current changes.

Figure 18: Shelving pending changes

Pressing the Shelve button takes you to the shelve dialog (Figure 19).

Figure 19: Shelving

You should always give your new shelveset a proper name (when you shelve changes a shelveset is created, similar to a changeset). You can also include a comment, link to work items and add notes. See the “Preserve pending changes locally” checkbox? You keep it checked when you want to take a checkpoint, you uncheck it in case you want to rollback.

Later, when you are ready to retrieve your shelved changes, you go back to the pending checkin window and press the Unshelve button to open the Unshelve dialog (figure 20).

Figure 20: Unshelving

This dialog shows you all your shelvesets. Selecting a shelveset and pressing the Unshelve button does the trick. You can also look at shelveset details or delete one. You can look – if you’re allowed to - at other developers their shelvesets by entering their name in the Owner name box. This way you can share unfinished changes with others. For example, some methodologies require buddy code-reviews before checkin. In this case, you shelve your changes, notify your buddy who can unshelve your changes and look at them.

Working Remotely

Many companies have development teams who work remotely, either because the company has out-sourced some parts of the system or because of lack of office space or simply because some specialized teams live and work in another country. VSTS RTM will support teams working over the internet using secure HTTPS. Microsoft is currently using VSTS themselves in 6 different locations, based in 4 countries on 3 different continents!

Hands-On

Ready to get your hands dirty? In this hands-on lab you will create a simple windows application to work with VSTS source control. You will do stuff like branching, merging, and shelving.

This lab is based on Visual Studio Team System Beta 2. If you don’t have team system installed, the fastest and easiest way to get started is to download the VPC image from MSDN subscriber downloads. This VPC image was also handed out at TechEd in Amsterdam.

Other releases might change some of the windows, or the way you do things. I’ll do my best to keep this article up to date when newer versions arrive (especially RTMJ).

Step 1: Create a team project

The first thing we need to do is to create a new team project. Team projects include the source control repository, work item system, reporting and so on. We are going to create a team project called HOL, but if you want to you can choose another name. Don’t forget to map your name instead in later steps.

Start Visual Studio 2005 and open Team Explorer using the View menu.

Tip: In case you get any error connecting, open a command window and run IISRESET.EXE. The Burton Integration Service (BIS) sometimes needs to be reset and doing an IISRESET does the trick.

Click on the “Add New Team Project” button (HOL figure 1)

HOL figure 1: Add New Team Project

This opens the Team Project Wizard (HOL figure 2):

HOL figure 2: Name the new team project

Name your team project HOL and optionally give it a description. Go to the next step (HOL figure 3). In this step you select the methodology you’re going to use for your project.

HOL figure 3: Select team project methodology

Keep the default and go the next step (HOL figure 4). In this step you create the team project’s portal, where people who are involved in the project can look at documents and reports.

HOL figure 4: Select team project portal

Keep the default and go to the next step (HOL figure 5). In this step you can create a new team project source control repository, or you can branch from an existing repository (for example when creating version 2 based on version 1).

HOL figure 5: Select team project’s source control

Again take the default and go to the last step. Here you get an overview of the team project’s options. Simply hit Finish. The wizard now creates your new team project taking a couple of minutes. Be patient. You should see HOL figure 6 if successful.

HOL figure 6: Team project created OK

Should things go wrong do an IISReset and try again, but pick another name for your team project.

Step 2: Add a work item to create the windows application

Before we start writing any code we are going to create a new work item using Visual Studio. Open Team Explorer and open your team project (HOL figure 7)

HOL figure 7: Team Explorer with new project

Right click the Work Items folder and select Add Work Item -> Task. A new work item will open. Enter “Create a new Windows application called HOLWin” as title. Save your work item. Create another task with title “Add an about button to the main form” and save it.

Step 3: Create a new Windows application

Create a new windows application called HOLWin for your language of choice. Do NOT check the “Add to source control” checkbox.

Step 4: Setup source control

In this step we’re going to add a couple of checkin policies to ensure every checkin has at least one work item associated and that sources compile. Right-click your team project and select Team Project Settings -> Source Control… from the context menu. This opens the Source Control Settings dialog. The “Checkout settings” tab allows us to choose between single and multiple checkout. Keep the default (multiple checkout). The “Checkin Policy” tab allows us to define the project’s checkin policies. Use the “New…” button to add the “Clean build” and “Work Items” policy. The work items policy requires a message in case team members don’t associate a work item. Enter “Associating work items with checkin is essential for good reporting” as the message. Click Ok to close this window. Finally, the checkin notes tab allows us to add additional notes for checkin, for example who reviewed the code, or you can create a custom note. We’re not going to use these, so close the window by clicking the Ok button.

Step 5: Add the solution to source control

Now we’re ready to add our solution and project to source control. Open the solution explorer, right click the solution and select “Add solution to source control…” from the context menu. This opens the “Add Solution to Source Control” dialog (HOL figure 8)

HOL figure 8: Add solution to source control

Simple click Ok to accept the defaults. However, the solution was only added to the workspace and we need to checkin our changes. So open the “Pending Checkin” window using the View menu. The first tab shows the changes that will be checked in. Please note that the solution and project’s files will be added (HOL figure 9)

HOL figure 9: Pending checkin window showing files to be added to source control

The second tab allows use to associate work items with the checkin (HOL figure 10).

HOL figure 10: Pending checking allows us to associate work items

Don’t associate any work items yet. The third tab contains custom notes (HOL figure 11).

HOL figure 11: Pending checkin with custom notes like code reviewer

The final tab contains any policy violations. We get two violations, first because we didn’t compile yet and another one because we didn’t associate a work item. So let’s fix these violations. Compile the project using the build menu. Then associate the “Create a new Windows application called HOLWin” work item by checking it in the second tab. We’re going to resolve this work item (it will be closed) so make sure the checkin action is set to “Resolve”.

Tip: If you go back to the policy violations tab you will see that it still complains about the build. Don’t worry; this is a bug in beta 2.

Now hit the checkin button. Wait for checkin to complete.

Because we resolved our work item you should see the status of this work item go from Active to Closed. Verify this by expanding the Work Items and Project Queries folder in Team Explorer. Double click the “All Tasks” query to execute it (HOL figure 12).

HOL figure 12: All tasks after checkin

Step 5: Add a work item to rename the form

Oops! The form is still called Form1. Let’s fix this. First we need a new work item so create a new task with title “Rename Form1 to MainForm”. Don’t forget to save.

Step 6: Rename the form

Go to solution explorer and rename Form1 to MainForm. A nice touch in Visual Studio 2005 is that the class behind this form is automatically renamed when you rename the file. Another nice touch is that VSTS does not ask you why you want to checkout the file (called silent checkout); VSS has this nasty habit of asking why you want to checkout a file. Typically this is when you start typing code, with most of your code ending up in the comments section of the dialog opened. I personally hated this VSS feature (and I am happy to say you can disable it).

Solution explorer now displays what files you have checked out (HOL figure 13)

HOL figure 13: Solution explorer showing checked out files

Go back to the pending checkin window. You’ll see that some files were edited, while Form1 was edited and renamed (HOL figure 14). You’re actually seeing the pending changes kept in your workspace.

HOL figure 14: Pending checkin window showing changes in workspace

Build the solution and associate the “Rename Form1 to MainForm” work item, then checkin.

Tip: you might need to refresh the work items list before you’ll see your latest work item.

Step 7: Checking history

Let’s make sure everything went right. Select History from MainForm’s drop-down menu. You should see MainForm’s changesets (HOL figure 15)

HOL Figure 15: MainForm’s history

Changeset 13 (you might have other changeset numbers) is where we added the project to source control, and changeset 14 is where we renamed form1 to MainForm. Anyone getting MainForm’s latest version will automatically have their Form1 renamed to MainForm because VSTS replays the changesets locally.

You can also right-click any changeset to compare it, or look at details (HOL figure 16)

HOL figure 16: ChangeSet 14 details

Step 8: Add the about button to the form

We still need to do the “Add an about button to the main form” work item. So add an about button to the form and add a click handler (with typo!). I’ve written this one in C# but calling a Messagebox in any other language is very similar!

private void About(object sender, EventArgs e)

{

MessageBox.Show("Team System Roks!");

}

Again checkin your changes after building the project and associating the work item. Let’s say this is version 1.0 and we are ready to ship.

Step 9: Create Version 2.0

Now we’re ready to start working on version 2.0 so let’s create a new branch to host this new version. First create a new task work item called “Create version 2.0”. Don’t forget to save it.

Open source control explorer using View -> Other Windows -> Source Control Explorer.

Tip: if you don’t see your project, you can refresh it by selecting the Workspaces command from the File -> Source Control menu, and closing the window again.

To branch to a new version right-click the folder containing your solution (HOL figure 17) and select Branch...

HOL figure 17: Before branching the solution

This opens the Branch dialog (HOL figure 18)

HOL figure 18: The branch dialog

Name the new branch $/HOL/HOLWin-V2 and click OK. Now you will see the branch in source control explorer (HOL figure 19).

HOL figure 19: After branching the solution

See the pending change? We still need to checkin to commit the branch to source control. Right-click the solution file (HOLWin.sln) in the HOLWin-V2 branch and select View. Viewing a solution opens the solution in Visual Studio. We can actually make a change before checkin, so let’s change the caption of the MainForm to “Version 2.0”.

Build the solution, associate with the “Create version 2.0” task and checkin.

Now we’ve branched version 2.0.

Step 10: Fixing a bug in version 1.0

Remember the typo in the Messagebox? We’re going to fix it in version 1.0, and then merge this bug fix to version 2.0. Start by creating a new bug work item. This is similar to creating a task work item, except you select Add Work Item -> Bug. Give the bug a title “Fix typo in about messagebox”. Save the bug work item.

Next step is to fix the bug, so we’re first going to open version 1.0 of our project. Open source control explorer, right-click the solution file and select View from the menu. This opens version 1.0 in Visual Studio.

Change the About button’s click handler to fix the typo:

private void About(object sender, EventArgs e)

{

MessageBox.Show("Team System Rocks!");

}

Build and associate the bug work item to checkin. Make sure you note the changeset number (You can find it in the output window or on the button of VS).

Step 11: Merging a bug fix to version 2.0

Now we’re ready to migrate this bug fix to the other version. First we need a work item. We’re actually going to create a new work item linked to the bug work item. Execute the “Resolved bugs” project query. You should get our previously fixed bug. Right-click the bug and select “Add Related Work Item -> Task”. Rename this new task to “Migrate work item 66 - Fix typo in about messagebox - to version 2.0”. Imagine the project lead doing this, linking the bug to this work item so another developer can easily find the original bug and retrieve the changeset(s).

Now open source control explorer. Right-click version 1.0 and select “Merge” from the drop-down menu. This opens the Version Control Merge Wizard (HOL figure 20)

HOL figure 20: Merging branches

Make sure you select ‘Only selected changes in the source branch” (not that it really matters since we only have one changeset, but it illustrates the concept better).

Hit next. Select your changeset from the list (there should be only one), then hit next then finish.

Remember that we changed the form’s caption in version 2.0? Well, the merge operation detected this and notifies us of a merge conflict (HOL figure 21)

HOL figure 21: Merge conflict

We can now resolve the conflict either manually or automatically. Hit the “Auto-Merge All” button to try to resolve the conflict automatically. This should work fine. Later we will resolve a merge conflict manually.

Merging does not checkin the merged changes because merging files could give compile errors. So let’s go to version 2.0 to see if the merge was done correctly, and to see if everything works fine. Again go to the source control explorer and view version 2.0’s solution to open it in Visual Studio. Make sure the caption is fine (“Version 2.0”) and that the typo is gone. Build and associate with the migrate task, and then checkin. Nice!

Step 12: Shelving because of interrupted development

Now we’re going to use shelving in an interrupted development example. First make the following change to the About-button click handler:

private void About(object sender, EventArgs e)

{

for( int i = 0; i < 2; i++

MessageBox.Show("Team System Rocks!");

}

Just image this is about 2 days of workJ. Now your boss walks in and she asks you to give a demo for a customer, immediately. And they want you to change the message so the customer’s name is displayed. Ok, no problem. First we are going to shelve our changes so we don’t lose two days of work. Open the pending changes window and click on the Shelve button. The Shelve dialog (HOL figure 22) opens. Name the shelveset “Work in progress interrupted”, enter a comment to help you remember the purpose of the shelveset, and uncheck the “Preserve pending changes locally”. Click on the Shelve button. You might see some windows being shown and hidden again, don’t worry; this is currently a bug in beta 2.

HOL figure 22: Shelving our changes

Because we unchecked the “Preserve pending changes locally” option VSTS will undo our changes, reverting back to the original version. Now we’re ready to display the customer’s name to the original code, so we change to code as follows:

private void About(object sender, EventArgs e)

{

MessageBox.Show("Welcome to U2U");

MessageBox.Show("Team System Rocks!");

}

Please note that we change the same line we had changed in our work in progress. This will require us to manually merge incompatible changes to this file later on.

Now we’re ready to build and checkin. Because we did not associate a work item we get a policy violation. We are going to ignore this policy for this one time (we need to give a demo in a couple of minutes) so check the “Override policy failure” checkbox and enter a reason (HOL figure 23)

HOL figure 23: Overriding a policy failure

Ok, demo time. We give the demo and the customer is happy. We go back to work; so we unshelve the work in progress shelveset. Go to the pending checkin window and click on the Unshelve button. Select your shelveset and hit the Unshelve button. Please note that we get the original source, without the extra message for the customer. This is good; since we’re in the middle of a complex piece of development we don’t want the added complication of other pieces of code. Complete the implementation:

private void About(object sender, EventArgs e)

{

for (int i = 0; i < 2; i++)

{

MessageBox.Show("Team System Rocks!");

}

We now checkin changes (either create a new work item, or ignore policy). Because we have some incompatible changes VSTS will ask us to resolve these (HOL figure 24):

HOL figure 24: Resolve checkin merge conflicts

Click on the Resolve… button. This opens the resolve version conflict dialog (HOL figure 25).

HOL figure 25: Resolve version conflict

There are several ways to resolve a conflict. You can keep your changes and throw away the other changes, or you can throw away your changes and keep the other. Or you use a merge tool to merge both changes. We are going to do that by selecting “Manual merge”. This open the VSS merge utility (HOL figure 26).

HOL figure 26: Merging changes

Click on the changes in the order you would like them, and in the bottom pane you can make specific changes, like delete repeated lines. Now, when you’re ready, click OK. You will be asked if you’re happy with the changes and if you want to keep them. Click “Yes” twice, and then close the Resolve Conflicts dialog.

Now we’ve merged the two versions we compile to make sure there are no compile errors, and we checkin again. Phew, we’re done.

Conclusion

Visual Studio Team System source control has a range of features essential for developing quality enterprise applications, such as a mature implementation for branching and merging multiple versions. Shelving allows use to do interrupted development, easily take checkpoints, or share incomplete sources between developers without affecting the rest of the team.

References

Visual Source Safe home page

Source Control HOWTO

MSDN Team System Web site: http://msdn.microsoft.com/teamsystem

About the author

Peter Himschoot is an architect and trainer for U2U, specializing in .NET, Team System and BizTalk. He is also a Microsoft Regional Director (http://www.microsoft.com/belux/nl/msdn/community/regionaldir.mspx ). You can reach him at peter@u2u.net.