Do check-in comments not get copied on a merge?

May 20, 2010 at 3:15 PM

Let me make sure I understand something.  I have a main, I create a devlopment branch. 

A programmer named John Doe makes a change in the development branch and checks it in.   During his check-in he puts a really nice description of the change such as:

     "My boss Suzie told me to fix this by changing the way we compute xyz."

Now later, another guy, let's call him Fred is the "referee" and is the only person in charge of merging all developer changes back to "Main".   So Fred does the Merge, the changes are on his disk, and then Fred needs to check them in.  In addition to John's change above, he also picks up a few changes by Sue.  So now, if someone looks at the change history of Main, they would only see the changes by Fred.  All the TFS check-in comments entered by John and Susan are effectively lost in the Main.

1. Is this correct? 

2 If so, then is it really useful to enter descriptive check-in comments into TFS itself?  Or is it better to put all the comments in the code itself? 

3. What comments should Fred enter for his TFS check-in (just something like "Merge on 05/19/210" or "weekly merge")?


Neal Walters

May 20, 2010 at 3:38 PM


Thanks for posting your question to this forum.

When a developer checks changes into the Development branch, a changeset is created and all of the changed files that are checked in at the same time are associated with this changeset. The developer should ALWAYS enter check-in comments to describe the change, as you note above.

Later when the Development branch is merged (RI) back to the Main branch, another changeset will be created on the Main branch. When these changes are checked, the person in charge of doing the merge should also enter a check-in comment.

You do not lose the check-in comments done earlier against the development branch. But you would need (in TFS 2008) to view changes against that branch to see the changeset history and associated check-in comments.

 As for what comments Fred enters on a merge changeset.. it probably is not important to enter more than "weekly merge". The changeset will have a date and time stamp. If you do a regular merge, vs. a special request merge the comments might indicate that. You might for example merge Main to Dev nightly, while you would wait for a milestone in Dev to pass quality gates before merging Dev back to Main. Here you might enter the milestone description in the change comment.

Bill Heys
VS ALM Ranger

Jul 8, 2010 at 6:52 PM
Hi Bill, While I think you are correct, the answer is not satisfying and I wonder if there is not another solution. Here is why, Yes, the comments (of course) stay on the development branch. But it is unfortunate that they are not also brought down to the MAIN branch with the code. The reason this is a drag is because when we generate our changeset on the MAIN branch (using TFS Sidekick even) we don't get the original comments the developer checked in on DEV. We only see Freds comments, which says "weekly merge". So we need to manually go back and get the changes on the DEV branch, which if different people RI back to main at different times - or over a long period of time due to a long QA cycle - this is a real pain in the neck. It would be better (and expected behavior) that the original change set and comment was truly MERGED into MAIN. Not a new change set and a new comment. Any ideas on how to resolve this? Thanks Jess
Jul 8, 2010 at 7:35 PM
Edited Jul 9, 2010 at 12:33 PM


I don't have a good answer for you. Part of the challenge is the possibility of having to save a huge glob of text that represents the concatenation of the changeset comments for all the changesets that participated in a merge. Take for example a feature development. You don't want to merge the feature team branch into Main unless and until it passes predetermined quality gates.

Over time there could be dozens or hundreds of changes checked into the feature branch. How would changeset comments for these be stored in the main branch on a merge? What maximum limit to merged changeset comments would you propose?

What would happen when you merge from Main into other branches and then back to Main. It seems you will have a recursive comment.  For this and many other reasons, I think I disagree that this would or should be expected behavior.

VS 2010 and TFS 2010 offer improved view of changes across branches. Checkout branch visualization, view history, and changeset tracking.


Bill Heys
VS ALM Ranger