Understanding ChangeSets and Merge with Team Foundation Server

http://weblogs.asp.net/dmckinstry/archive/2006/07/03/Understanding-ChangeSets-and-Merge-with-Team-Foundation-Server.aspx

Understanding ChangeSets and Merge with Team Foundation Server

Published 03 July 06 09:42 AM | dmckinstry

I just completed some work with a client, helping them understand how to model and manage their change management and build processes.  Although the specific promotion modeling, etc, is ripe for a different posting, right now I'd like to return to the basics of Team Foundation Version Control (TFVC).

If you're using TFVC, you're probably already familiar with the term "changeset."  You likely know that a changeset represents a group of versioned files along with associated meta data such as policy information, timestamps, comments, and the like.  What you may not understand is that the 'versioned files' are actually understood by TFVC as the changes between version.

This is a fairly big deal.  If you need to selectively merge changes, changesets provide the ability to do just that.  Consider the following three file versions...

(Baseline version)	(Changeset A)	(Changeset B)
... public void method1() {   // placeholder } public void method2() {   // placeholder } ...	public void method1() {   // Code added   // etc. } public void method2() {   // placeholder }	public void method1() {   // Code added   // etc. } public void method2() {   // Different code   // added }

It is probably easy to understand that if I have a branch based on the baseline version and merge Changeset A that the results will be the same as the file listed in changeset A.  What causes some people confusion is that when I start with the baseline and merge only Changeset B, I get a result that is neither A nor B.  Instead I get the base line with only the changes from A to B applied.  The results look more like this:

(Baseline with Changeset B applied)

public void method1()
{
  // placeholder
}

public void method2()
{
  // Different code
  // added
}

This is great if what you need is the ability to manage changes pushed between environments.  You still have the ability to merge up to a given version.  That is if I had merged to version Changeset B instead of just merging the selected changeset B, I would have ended up with the changes for both A and B.

I've sidesteps questions such as merge conflicts and a suite of other discussions.  But this understanding by itself can make a big impact to how you plan and manage changes in your TFS source control systems