Introduction to Source Control ---

Overview Whether your software project is large or small, it is highly recommended that you use source control as

early as possible in the lifecycle of your project. Even if you’re working alone on a small project, you can

use source control to improve your personal productivity and recover from difficult problems. In fact,

there is a lot of benefit from using source control from the beginning of your team project, including the

ability to easily revert to previous versions of the codebase. If you work with a team or on complex

projects, you should almost certainly work in a shared, version-controlled file system so that you can

improve collaboration and transparency. You can also take advantage of integrated automated builds,

project planning and tracking, and other Application Lifecycle Management capabilities if you use Visual

Studio Online or Team Foundation Server.

In this scenario, you’re a developer at a software company. Your company builds a fairly simple WPF

application, but has the need for regular changes. Since there are multiple developers who need access

to the codebase, access is gated by using the source control provided with Visual Studio Online.

Objectives In this hands-on lab, you will learn how to:

- Set up a team project using Visual Studio Online

- Add a solution to source control

- Manage and document the codebase over time

- Search, branch, and merge the codebase

- Take advantage of source control features of Visual Studio Online

Prerequisites The following is required to complete this hands-on lab:

- Microsoft Visual Studio 2013 (with Update 2 RC applied)

- A Visual Studio Online account

Notes Estimated time to complete this lab: 60 minutes.

Note: You can log into the virtual machine with user name “User” and password “P2ssw0rd”.

Note: This lab may make references to code and other assets that are needed to complete the exercises.

You can find these assets on the desktop in a folder named TechEd 2014. Within that folder, you will

find additional folders that match the name of the lab you are working on.

Exercise 1: Setting up your project and environment In this exercise, you’ll go through the process of setting up a new team project using Visual Studio

Online and configuring your development environment to use it.

Task 1: Creating a Visual Studio Online team project In this task, you’ll create a Visual Studio Online team project. This project will ultimately house the code

for your company’s product, which will be accessed by the other developers and team members at your

company.

1. When you created your Visual Studio Online account, you set up a domain at visualstudio.com.

Navigate to that domain and log in. The URL will be something like https://MYSITE.visualstudio.com.

2. Under the Recent projects & teams panel, click the New link.

3. In the Create new team project dialog, type “Source control” as the Project name and click Create

project. It may take a few minutes for your project to be created. Note that you can use any name

you like for this project, although the screenshots will not match.

Note: This lab uses the default Process template and Version control options. Depending on the

nature of your project, you may opt to use one of the other options. For version control, Visual

Studio Online also fully supports the Git model. While there are some differences between the way

the default Team Foundation Version Control and Git work, the fundamentals of source control are

largely the same, and virtually everything covered in this lab applies to both.

4. After the project has been created, click Navigate to project.

5. On the project’s landing page there are plenty of options for what to do next. The first thing you

should do is create a backlog item to create the initial project. Click Create new | Product Backlog

Item to create your first backlog item for this project.

6. In the New Product Backlog Item dialog, type “Create initial project” and click Save. On a real

project you’d want to fill out more of these fields and assign it to someone, but for the purposes of

this lab you can keep it simple.

7. After the item is saved, it will update the ID near the dialog title. Make note of this ID because you

will use it later to associate the work item with a check in. Press Esc to close the browser dialog.

Task 2: Configuring Visual Studio to work with your project In this task, you’ll configure Visual Studio to work with your project. These steps will need to be

performed for each machine you want to develop on.

1. Launch Visual Studio 2013.

2. In Team Explorer - Home, click the Connect to Team Projects button.

3. Next, click Select Team Projects….

4. In the Connect to Team Foundation Server dialog, click Servers….

5. In the Add/Remove Team Foundation Server dialog, click Add….

6. In the Add Team Foundation Server dialog, type your visualstudio.com domain as the Name or URL

of Team Foundation Server and click OK. If asked to sign in, use the same Microsoft account you

used to create the Visual Studio Online account.

7. In the Add/Remove Team Foundation Server dialog, click Close.

8. In the Connect to Team Foundation Server dialog, check the Source control project and click

Connect. Visual Studio will now connect to your project and perform some basic configuration to

allow access to source code, work items, and other useful project assets.

9. In Team Explorer, there are now several options for interacting with the newly created project. Click

the Home button followed by Source Control Explorer to see the source code.

For a new project, the source code repository is empty, with the exception of some default build

process templates. You’ll also notice that the text for the project is grey, which indicates that you do

not have the latest version. However, before you can get the latest version (or add files), you’ll need

to map a local folder.

10. In Source Control Explorer, right-click the root collection node (which should be

[yoursite].visualstudio.com\DefaultCollection) and select Advanced | Map to Local Folder….

11. In the Map dialog, select a local folder where you’d like all your source to be downloaded to. Note

that this is a folder you can interact with outside Visual Studio, and those changes will be treated the

same as any. Click Map to complete the mapping.

12. After mapping, Visual Studio will provide the option to download the latest version of all files within

the mapped project. Click No to skip this process for now.

13. Right-click the Source control project and select Get Latest Version. This will be the way you get the

latest version of most projects and files.

If you navigate to the folder you mapped earlier using Windows Explorer, you should see that a

Source control project folder has been added to it. Within that folder is a single

BuildProcessTemplates folder with some XAML files.

Task 3: Adding a solution to source control In this task, you’ll use Visual Studio to create a new project and add its solution to source control. After

the project is in source control, other team members will be able to download it, track it, and submit

changes.

1. From the main menu, select File | New | Project….

2. In the New Project dialog, select the Visual C# | Windows category and the WPF Application

template. Leave the default “WpfApplication1” project name and set the Location to the path of

your project folder for the Source control project. Click OK to create the project. Note that there is

an option to add the project to source control immediately, but you won’t do that here.

3. Once the project is created, you can add its solution to source control. In Solution Explorer, right-

click the solution node and select Add Solution to Source Control….

4. In the Choose Source Control dialog, select the Team Foundation Version Control option and then

click OK.

5. In the Add Solution WpfApplication1 to Source Control window, use the default options to add to

the Source control project in a folder named WpfApplication1. Click OK to continue.

6. When a solution is under source control, Visual Studio will indicate the status of files by adding a

glyph, such as the plus signs that indicate which files have been added, but not yet checked in.

7. Right-click the solution node and select Check In…. This will bring up the Team Explorer on its

Pending Changes page. Note that you could have simply navigated to this view using Visual Studio,

although the Solution Explorer method has the benefit of automatically including the files within

the scope of the right-click.

8. In Team Explorer, you can see all the files to be included with this check in under the Included

Changes section. Right now there are fourteen, which is the entire solution. You could decide to

exclude some of these if you desired, although that would potentially break the project for someone

else who downloads it later.

After performing a check in, the included files become known as a changeset. Changesets are a

common way for searching through project history. For example, if the current check in is designed

to update files and fix a bug, you would want it to be easy for someone to understand everything

that was changed as part of the process to address that bug.

9. You can also associate work items to the check in, such as the product backlog item created earlier.

Click Add Work Item by ID and enter the work item ID generated for the product backlog item

created earlier. Click Add to associate it with this check in.

It will now be associated with this check in, and people will be able to easily find the changeset from

the work item later on.

10. Finally, you’re ready to submit the check in. Type “Initial check in” as the Comment and click Check

In. If asked to confirm the check in, click Yes. You may also want to check the Don’t prompt again

box to avoid getting asked every time you check in.

After the check in has succeeded, it will be assigned a changeset ID.

11. In Solution Explorer, you will now notice that the glyphs next to each file icon have turned into little

locks. This indicates that the files are checked in.

12. Switch to the Source Control Explorer window.

13. Navigate to Source control/WpfApplication1/WpfApplication1. You’ll see the list of files included as

part of the server-side project, as well as their current status, whether you currently have the latest

version, and the last time the file was checked in.

Exercise 2: Working with source control in Visual Studio In this exercise, you’ll create a label to make finding a version of the codebase easier to track down.

You’ll also go through the process of checking out files, editing them, and checking them back in. Finally,

you’ll learn about how to undo your most recent changes.

Task 1: Labelling a version in source control In this task, you’ll create a label in source control. A label is simply a marker tracked by the source

control system that enables you to quickly find a snapshot of the project in source control. You’ll also

learn how to search for specific versions of files associated with labels, as well as how to download

them.

1. In Source Control Explorer, right-click the Source control project node in the Folders pane and

select Advanced | Apply Label….

2. In the New Label dialog, type “Initial version” as the Name and select Latest Version from the

Version drop down. Click Create to create the label. Labels are often used to track specific release

versions and might have names like “v1.0” or “June 25 release”. Note that you also have the option

of selecting a version different from the current version, such as if you wanted to create a label for

the code base as of a specific date or after a specific changeset. You could also scope the label in to

a more specific part of the codebase.

3. In Source Control Explorer, right-click the Source control project node in the Folders pane and

select Find | Find Label….

4. In the Find Label dialog, select Source control as the Project and click Find. This will provide a list of

all labels in source control.

5. Double-click the Initial version list item to open a view into that specific version.

6. Navigate to Source control/WpfApplication1/WpfApplication1.

7. Right-click App.config. Note that there are some useful options available for working with this file in

the context of its label in source control. For example, you can change the version of this file that’s

included under this label. This could be useful if you made a change after applying the original label

and needed that change to be included with the labelled version for anyone who might want to

download it.

8. Close the label view.

9. In Source Control Explorer, right-click the Source control project node in the Folders pane and

select Advanced | Get Specific Version….

10. In the Get dialog, select Label from the Type drop down and click the Browse button.

11. The Find Label dialog is the same one you saw earlier. Select Source control as the Project and click

Find.

12. Double-click the Initial version list item to select it for the “get specific version” workflow.

13. In the Get dialog, click Get to get the specific version selected here. Note that you also have the

option to overwrite writeable files that are not checked out, or even to overwrite all files, even if the

local version matches the specified version.

14. In this case, all the files are already up-to-date, so you should be a dialog indicating that. Press Esc to

dismiss.

Task 2: Check out and check in In this task, you’ll check out a file, edit it, and then check it back in. When working with Visual Studio,

you’ll almost always work using your local workspace. Your workspace is your local copy of the team’s

codebase. This is where you develop and test your code in isolation until you are ready to check in your

work. In most cases the only workspace you need is created automatically for you and you don’t have to

edit it. While the process of editing still uses the “check out” concept, the “check out” is entirely local.

As a result, other developers can check in changes to the same files you’re working on, and there is a

process for dealing with merging conflicting changes that you’ll see later on.

Note: If your project is really big (hundreds of thousands of files), there is an alternative workspace

option known as the “server workspace” that may be a better option. For more guidance on using server

workspaces, please visit http://msdn.microsoft.com/en-us/library/bb892960.aspx.

1. In Solution Explorer, locate MainWindow.xaml and right-click it. There are a variety of source

control-related options, such as “Get Latest Version” and “Check Out for Edit”. While you could

select “Check Out For Edit” from here, sometimes it’s easier to check out files right as you’re about

to edit them. Press Esc to close the context menu without selecting anything.

2. Open MainWindow.xaml.

3. In the XAML editor, place your cursor just inside the closing bracket of the Window tag. Press Space

to start adding a new attribute.

Since this file is under source control, Visual Studio will automatically check it out for you.

4. From the main menu, select View | Output to bring up the Output panel.

5. Select Source Control - Team Foundation from the Show output from drop down. The last line

printed should show that MainWindow.xaml was checked out silently.

Note: There is a feature known as "Get latest on checkout" that is only available when working with

server workspaces. With this option, Visual Studio will automatically make sure you’re working with

the most recent version of a file when you check it out. If you’re working on a file that may be in

active use by other developers, it’s recommended that you regularly perform a “Get latest” in order

to avoid redundant work or creating additional merge rework later on.

6. After checking the file out, your cursor and focus are returned to where they were before, and

Visual Studio displays the IntelliSense dialog to offer help.

7. Add the following code to set the window background to blue.

XAML Background=”Blue”

8. Press F5 to run the application. The background will be blue. Close the application when satisfied.

9. In Solution Explorer, right-click MainWindow.xaml and select Check In….

10. In Team Explorer, type “Changed background to blue” as the Comment and click Check In.

Note: It's a best practice to perform a “Get latest” before checking in files. Due to the way various

developers can submit overlapping changes, there is a risk that a given checkin will work on your

machine, but that it may “break the build” of the server codebase due to a change made by another

developer since you got the latest version. This lab skips that step for the sake of brevity, but you

should always “get latest” in practice.

Task 3: Undoing pending changes In this task, you’ll undo a pending change. Sometimes you make changes and decide that you don’t want

to keep them. This could be for the entire set of checked-out files, or even just a single one. When you

undo changes, it simply replaces those files with the latest versions from source control. However, keep

in mind that this process is irreversible, so once you undo the changes, they’re gone forever.

1. In MainWindow.xaml, change the background color to red. You’ll need to approve the check out

along the way.

2. Press F5 to run the application. It will have a red background. Close when satisfied.

In this case, it’s clear that you don’t want a red background, and there’s nothing from these current

changes you’d like to keep. This is where “undo pending changes” comes in.

3. There are many places from where you can invoke the “undo pending changes” feature. In this case,

it’s easiest to right-click MainWindow.xaml in Solution Explorer and select Source Control | Undo

Pending Changes….

4. In the Undo Pending Changes dialog, confirm that it only includes the files you want to undo and

click Undo Changes.

5. As part of the process, Visual Studio will also undo the checkout of the files as well. Click Yes to

confirm. If you’re undoing multiple files, it’s easier to select Yes to All.

6. Press F5 to run the application. Note that the background has returned to the pre-checkout blue.

Close when satisfied.

Exercise 3: Advanced source control in Visual Studio In this exercise, you’ll take a look at some of the more advanced features of source control, such as how

to effectively search for code and compare versions. You’ll also learn about shelvesets, as well as how to

branch and merge the codebase.

Task 1: History, compare, and rollback In this task, you’ll use three related features of source control in Visual Studio: history, compare, and

rollback.

History allows you to search, filter, and view the past checkins of a given file. For example, you may

see unexpected behavior in the current codebase and want to understand what changes have been

made that might have caused it. History is also a great way to know who to blame if the build

breaks!

Compare provides an easy way to see the differences between the files. When you compare files,

Visual Studio will infer the adds, deletes, and changes at a per-line level. When possible, it will even

highlight the specific part of a line that has changed.

Rollback enables you to roll back a changeset in order to remove their changes from the codebase.

While that changeset still remains in the history, you can easily undo the effects by accessing the

earlier version and checking it back in as the latest.

1. In MainWindow.xaml, change the background color of the window to green. You’ll need to allow

the file to be checked out along the way.

2. Press F5 to run the application. The background is now green. Close when satisfied.

3. In Solution Explorer, right-click MainWindow.xaml and select Check In….

4. In Team Explorer, type “Changed background to green” and click Check In.

5. After the check in completes, right-click within the MainWindow.xaml file open in the XAML editor

and select Source Control | View History to bring up the history view.

6. The history view provides a list of all the checkins for this file. If you right-click on the second item,

you’ll see a lot of interesting options that allow you to see more details, compare with other

versions, get this specific version, or to even roll back the entire changeset. Select View.

7. Visual Studio will download that specific version of the file, which you can see is saved to a

temporary path and is read-only (the lock icon next to the path). You’ll also notice that the

background of the window is blue, confirming that it’s the previously checked-in version you

wanted.

8. Close the file.

9. In the history view, right-click the second item again and select Compare….

10. Visual Studio downloads the requested version and compares it to the one in your current

workspace, opening it in a diff (“differences”) window. On the right-hand side you can see the red

marker indicating where the earlier file has had lines changed or removed. The green marker

indicates where the later version has changed or added lines. If you look closely at the source files,

you can see that the “Blue” and “Green” text has been subtly highlighted because that is the specific

change detected in that line.

11. Close the diff window.

12. When you selected View earlier, it was noted that the file was downloaded to a temporary location

and set to read-only. However, sometimes you’ll want to pull that version into your project to work

with it directly. To do this, simply right-click that version in the history view and select Get This

Version.

13. Press F5 to run the application (or Debug | Start Debugging from the main menu). The background

is now blue because the earlier version was downloaded and compiled into this build.

Now that you’ve confirmed that this is the version you prefer to the green background, you can

continue working with this file and eventually check it in to become the latest version. However,

sometimes it’s not as easy as dealing with a single file, so it’s more effective to use the rollback

feature.

When you roll back a changeset, you’re effectively getting the latest version, but ignoring that

changeset and anything that came after it. One downside to this approach is that it rolls back the

entire changeset, so you need to pay special attention that you’re not overwriting changes you want

to keep elsewhere.

Note: Rolling back doesn’t actually delete the changeset. Changesets are permanent. Instead, a

rollback pulls down the specified version and treats any changed files like a pending change you’ll

need to check in later.

14. In the History - MainWindow.xaml window, right-click the most recent changeset and select Get

This Version. Ordinarily you wouldn’t need to do this step, but the current state of your workspace

happens to be exactly the same as what it will be after the upcoming rollback. As a result, the

rollback would fail because there would be no changes to make.

15. Right-click the latest changeset (the one where you changed the background to green) and select

Rollback Entire Changeset. If Visual Studio asks if you’d like to reload files that have changed, click

Yes to All. Remember that the version you select is being rolled back, so it’s actually the version

prior to that one that will be downloaded.

16. In Solution Explorer, note that MainWindow.xaml is now treated as a checked-out file (indicated by

the red check glyph next to the file icon). Right-click MainWindow.xaml and select Check In….

17. In Team Explorer, type “Reverted to blue background” as the Comment and click Check In.

18. In the history view for MainWindow.xaml, click the Refresh button. This will update the list to

reflect the most recent check in, which involved an edit and a rollback.

Task 2: Working with shelvesets and conflicts In this task, you’ll learn about working with shelvesets. Shelvesets are a convenient way to suspend and

share your work without checking it into the codebase. With a shelveset, you “save” your changes to the

server where you (or someone else) can pick them up to work on later. This is extremely valuable in

scenarios where you want to pause your work to take on a different task, such as fixing a bug with an

earlier version of the codebase. Another scenario where shelvesets are useful is when you need to share

the state of a project with another developer, whether they’re reviewing your work or continuing it

elsewhere.

1. Edit MainWindow.xaml to have an orange background. You’ll need to check out the file along the

way.

2. Press F5 to run the application. The background will be orange. Close the application when satisfied.

At this point, pretend that word has come down from your management that the orange

background work will have to wait. Purple is now all the rage, so you’ll need to get started on a

purple background. However, orange will eventually be the color the team needs to deliver at some

point, so it would be a waste to throw out all that work. This is a perfect time to create a shelveset

with your current changes.

3. In Solution Explorer, right-click MainWindow.xaml and select Shelve Pending Changes.

4. In Team Explorer, type “Orange background” as the Name and click Shelve. You’ll notice that the

shelveset experience is almost the same as the check in experience.

5. After the shelving process is complete, you’d typically undo changes or get a specific version.

However, since the changes involved in this lab are trivial, you can simply change the orange

background of MainWindow.xaml to purple.

6. Press F5 to run the application. The background will be purple. Close the application when satisfied.

7. In Solution Explorer, right-click MainWindow.xaml and select Check In….

8. Type “Changed background to purple” and click Check In.

After a little time goes by, management has returned to ask you to update the background to

orange, as originally planned. Fortunately, you have a shelveset with that change available, so you

can restore it into your workspace.

9. In Team Explorer, click Actions and select Find Shelvesets. This will bring up a list of your shelvesets.

10. There are two options to help filter down the list of shelvesets: by email and by name. Since you

probably don’t have that many in the list, locate and right-click the Orange background shelveset

and select View Shelveset Details.

11. In the Shelveset Details panel you can see what changes are included with the shelveset, as well as

the comment left, if any. It also provides an Actions list, where you can request a code review. Click

Actions | Request Review.

12. In the New Code Review panel, you can add the name of a reviewer (or pick from the drop down)

and assign an area path for the review. If you submit the request, they will be notified to pull down

your shelveset and review. Click Cancel.

13. To apply these changes back to the current project, click Unshelve Changes followed by Unshelve.

As the shelveset is being unshelved, Visual Studio notices that one of the changes included in the

shelveset conflicts with a more recent change to the same part of the codebase. Since this shelveset

changed the same background color that the more recent check in changed, Visual Studio can’t

automatically merge the changes for you. As a result, you are presented with the Resolve Conflicts

window, which provides as much detail as possible as to the files and versions involved. In some

cases (like this one), the easy answer is to restore either the original workspace or unshelved

versions. However, sometimes the changes are nuanced, and you’ll want to manually decide which

changes to keep from each. That’s where the Merge Tool comes in.

14. Click Merge Changes In Merge Tool. If asked about closing MainWindow.xaml, click Yes.

There are three documents opened in the merge view. The one on the left is the current workspace

version. The one on the right is the unshelved document being merged in. The bottom document is

the “final” version that the selected merges will be applied and shown in. Note that it defaults to the

most recent common ancestor of the two files being merged.

15. Since you want to keep the change from the shelveset, check the box next to that line. The shelveset

will appear in the right panel. Since it has been selected, the alternative option is faded and the

merged document at the bottom reflects the current version to be saved. Note that you can also

edit the bottom document directly if you need to.

16. You can now see that there are no remaining merge conflicts, so click Accept Merge.

17. Press F5 to run the application. The background will be orange. Close the application when satisfied.

At this point, MainWindow.xaml will still be checked out. Do not check it in.

Task 3: Branching and merging In this task, you’ll learn about branching the codebase, and then merging branches back together. In this

scenario, your company has landed a big customer that requires special customization throughout their

version. To begin with, they want their yellow brand to be used as the background color. The best way

to handle significant divergence is to branch the code.

1. In Team Explorer, click the Home button, followed by Source Control Explorer.

2. Expand the Source control project in the left pane, right-click WpfApplication1, and select

Branching and Merging | Branch….

3. In the Branch dialog, replace the “branch” in the Target path with “yellow” and click OK.

4. Open Windows Explorer and navigate to the source control location on your local disk. Notice how

there is now a new folder for the branch just created, and it’s almost the same as your original

branch.

It’s important to note that you still have one pending change in the original branch, which was when

the unshelved change switched the background color from purple to orange. When a branch is

created, it only uses checked-in code, so the new “yellow” branch is actually still operating with the

old purple color because it was copied from the server, not from the local project.

5. In Solution Explorer, right-click the solution node and select Check In….

6. Type “Changed background to orange” as the Comment and click Check In.

Now that you’ve checked in changes to the main branch, it’s time to work on the yellow branch.

Note that this is treated just like opening any different solution, so there is little overlap in the actual

development experience when working on a branch.

7. In Source Control Explorer, select the WpfApplication1-yellow folder and double-click

WpfApplication1.sln to open it.

8. In Solution Explorer, you’ll now see that all the files are checked out, which is because you’ve

opened a completely different solution from the one you just had open. It’s the branched solution,

but it hasn’t been checked in just yet. Open MainWindow.xaml.

9. Change the background color to yellow.

10. Press F5 to run the application. The background will be yellow. Close the application when satisfied.

11. In Solution Explorer, right-click the solution node and select Check In….

12. Type “Changed background to yellow” as the Comment and click Check In.

After a short while, the company has decided that all of the changes made in the yellow branch

should really be applied to the main branch. As a result, it’s time to merge the branches.

13. In Source Control Explorer, right-click the yellow branch and select Branching and Merging |

Merge….

14. In the Source Control Merge Wizard, there are options to select the source and target branches, as

well as which changes should be applied. Leave the defaults, which will merge everything from the

branch you clicked into its parent. Click Next.

15. Next, you can decide the Version type to merge. Accept the default and click Finish.

16. Since there was a conflict over the background color change, Visual Studio can’t automatically

complete the merge. However, you already know that the source branch (the “yellow” one) is the

file you want to keep. Click Take Source Branch Version. Note that you could click Merge Changes In

Merge Tool if you wanted to preview exactly which changes would be kept/lost.

After the differences from the yellow branch have been merged into the main branch, the yellow

branch remains unchanged. In this scenario, you could potentially delete that branch if you know it

will never be used again. However, in many cases a branch lives on, such as when you have branches

set up like “Main”, “QA”, and “Dev”.

17. In Source Control Explorer, select the main branch and double-click WpfApplication1.sln from the

contents pane to open that solution.

18. Press F5 to run the application. The background will be yellow. Close the application when satisfied.

19. Although you merged the branches successfully, you still need to check the changes in.

20. In Team Explorer - Pending Changes, note that the Included Changes section contains

MainWindow.xaml and lists its state as “merge, edit”.

21. Type “Merged yellow branch” as the Comment and click Check In.

22. After the check in succeeds, click the changeset link to view it.

23. In the Changeset Details pane, click Track.

24. The Tracking Changeset dialog enables you to track a changeset across branches. Expand the

Branches tree and check the child branch box. Click Visualize.

25. The default visualization provides a hierarchy tracking view of the changesets. Click Timeline

Tracking to view chronologically.

26. The Timeline Tracking view provides a different view on the same changesets. If you right-click a

changeset, it will provide additional options to manage the changeset itself.

Task 4: Source control settings In this task, you’ll learn about some of the source control settings you can tweak in Visual Studio, as

well as global settings you can configure to improve quality and transparency in the check-in

process.

1. From the main menu in Visual Studio, select Tools | Options.

2. Navigate to Source Control | Environment to bring up local options for source control.

There are a lot of options you can adjust to build your ideal environment. The default preset is Team

Foundation, in which all four options at the top are unchecked. The other preset is Individual

Developer, which checks all four boxes. Of course, you can always pick and choose which features

you want. You can also change the way Visual Studio treats checked-in items during the save and

edit processes.

3. Select the Visual Studio Team Foundation Server node in the left pane. This view offers additional

settings that are specific to working with Team Foundation Server and Visual Studio Online.

Note the option to Show deleted versions in the Source Control Explorer. In Visual Studio Online

source control, items are never discarded. As a result, deleting an item (and checking in the

“delete”) simply hides that file from view. You can still view its versions, content, changesets, etc.

4. Press Esc to close the dialog.

In addition to adjusting environment features, Visual Studio Online provides some great features to

gate the quality of checkins.

5. In Team Explorer, click the Home button, followed by Settings.

6. Click the Source Control link underneath the Team Project section.

7. In the Source Control Settings dialog, select the Check-in Policy tab and click Add….

A check-in policy is a rule that is enforced during the check-in process. There are four policies

available (but not enabled) by default. The Builds policy requires that the most recent build

succeeded. The Changeset Comments Policy (which you’ll add in a moment) requires that the

Comment field is filled out. The Code Analysis policy requires that code analysis be run before

check-in. Finally, the Work Items policy requires that at least one work item be associated with the

check in.

8. Select Changeset Comments Policy and click OK.

9. Select the Check-in Notes tab and click Add….

10. Type “Pair partner” as the Title and click Add. This will provide an additional (and optional) field for

the developer to fill out when checking in. If the developer worked with a pair programming partner

on this check in, they can be associated with it for further questions, etc.

11. Click OK to close the Source Control Settings dialog.

11. Open MainWindow.xaml.

12. Make a minor edit to MainWindow.xaml, such as an additional space in the existing whitespace.

The goal is just to invoke a checkout.

13. In Solution Explorer, right-click MainWindow.xaml and select Check In….

14. Notice that the check in experience now has a policy warning to remind you to include a comment,

as well as a field for the “pair partner” added earlier. Provide some text in each and click Check In.

Exercise 4: Visual Studio Online In this exercise, you’ll take a look at some of the features made available for source control on the Visual

Studio Online project site.

Task 1: Your Visual Studio Online project portal In this task, you’ll take a tour of the source control features available on Visual Studio Online project

portal.

1. In Team Explorer, click the Home button and then click the Web Portal link. Sign in if asked.

2. From the tab menu near the top, click Code to view the codebase.

3. In the left pane, click WpfApplication1 | WpfApplication | MainWindow.xaml. It will load the

current version of the file in the right pane. Note that you have the option to download the file

directly from the browser.

4. Click the Compare tab above the code. This will bring you to a side-by-side comparison of the file

with its previous version. Note that you could also select different versions to compare from and to.

If you click the Mode button on the right side of the toolbar, you can switch from side-by-side to

inline diff mode.

5. Click the History tab to see all the changesets this file was a part of. Expand the Show merge history

link to see details about the recent file merge.

6. This merge was part of a branch merge, so you can click Show branch history to see the details of

the branch itself.

7. Click the Merged yellow branch link from the most recent changeset.

8. Now you can see more details about this recent change. However, you can go a step further and

provide a lightweight code comment to annotate the history of the file. Place your mouse over the

margin to the left of the line numbers and click the Add Comment button that appears.

9. Type “Yellow looks better.” as the comment and press Enter.

This comment is now part of the changeset and can be viewed by anyone reviewing the code. They

can also reply or ask questions, which provides a great way to communicate and document the

project’s history.

10. Click the Changesets tab to bring up the history for this project. Note an icon now appears to

indicate that this changeset has some lightweight code comments attached.