TFS Basics–Changeset

When I talk to customers about how they keep track of changes of their source code, you may (or may not) be surprised with what I hear. They range from using some source code control management (SCCM) tool to archive files using ZIP or RAR files. Hopefully you're using a SCCM tool.

As part of the development process, developers can either been given tasks through a system like Team Foundation Server (TFS), a project plan, or some other means like email. The important thing to think about is tracking the developer’s work back to the changes in code.

When I was wrote code full time, I often would try to resolve as many tasks as I could if the code changes were related to the same modules(s). Sometimes this was effective con clearing out a bunch of work off my plate, but when it came to integration time with the rest of my team, we could end up with a lot of changes we would have to reconcile and integrate.

Regardless of the development process you adhere to, it’s really a good idea to encourage developers to work at one task at time, only change the code related to the one task, and integrate often. This makes finding out where incorrect code changes are made and corrective actions can be done quickly. Even using continuous integration techniques isn't going to help figure out what changes broke if you try to change too many requirements at one time.

With Team Foundation Server (TFS), we don't force you to work in any particular manner; however, it is encourage that you work on one task at a time for better traceability. Assuming you use TFS for work management as well as SCCM, upon code check in, you can enforce (or encourage) that all code that is checked in be associated with a work item. A work item can be defined to be anything you'd like it to be: bug, developer task, test case, user story, requirement, and so on.

The Changeset

When you check in code into TFS, a changeset is created. A changeset is a set of files and work items associated together a time of check in. If you don't associate work items with the code, the changeset will just consist of just the set of files. The heart of this is due to the fact that the check-in process is an atomic transaction. When you perform a check in, the process tells TFS how many files and work items are going to be checked in. Assuming all the files get transferred properly into TFS, TFS will generate a changeset number. This number can be used to trace back what code files and work items were worked on.

In the following screen shot, Changeset 89 is made up of 1 code file and 1 work items. Obviously this is pretty simplified, because all the code changes made were in one file related to one task. Even if it wasn’t and you had multiple changed files to one task, you can see that all the code changes that were related to the one task.

Code Annotation

A lot of development groups try to encourage their developers to document every change that is made in code. Sounds good in principle but difficult to implement in practice. Why? Because you might end up with more comments than code, or you might end up with a situation where you have comments inside logic blocks just to show where code changes were.Your modules might start looking like this:

 Me.GetPeopleButton.Font = New System.Drawing.Font("Microsoft Sans Serif", 8.25!, System.Drawing.FontStyle.Regular, System.Drawing.GraphicsUnit.Point, CType(0, Byte))
Me.GetPeopleButton.ForeColor = System.Drawing.SystemColors.ControlText
 ' 2012-12-03 NI - Task 24 – Block Start
Me.GetPeopleButton.Location = New System.Drawing.Point(6, 376)
 ' 2013-02-04 AJ - Task 42
Me.GetPeopleButton.Margin = New System.Windows.Forms.Padding(4, 3, 4, 3)
Me.GetPeopleButton.Name = "GetPeopleButton"
 ' 2013-02-16 KB - Task 47
Me.GetPeopleButton.Size = New System.Drawing.Size(124, 23)
 ' Task 24 – Block End
Me.GetPeopleButton.TabIndex = 0

You certain don’t want to discourage your developers from putting in comments, but there is another way to look at what lines of code were changed, by whom, when, and why. This is the Annotate feature. To access this feature, its found in the content menu in the Source Code Explorer when you're looking at a file's history list.

When you view the Annotation of the file, in the left hand margin, you will see the changeset number, the name of the person who made the modification, and the time of the change. The changeset number is a hyperlink so if you click on it, you will be able to see what file(s) and work items are associated with the changeset. This can be really useful if trying to figure out who made a particular code change -- because you'll see who made the code changes -- and why -- assuming the changeset has a work item associated with it. You still want to encourage your developers to add comments to their code, but if they forget.

Excelsior!