views:

143

answers:

2

What is the best way to check-in merges when it comes to indicating what is being merged? I have say 10 changesets I am merging from my main branch to a release branch. Each of those contains detailed comments that I have written when checking in to the main branch. Now when I am merging I find myself and other members of the team writing short versions and even missing or not mentioning the things being merged. Therefore I am wondering if we are doing this completely wrong somehow and if there is a way to point to the changeset that we are merging into the release branch?

We are using Team Foundation Server.

A: 

Can't you assign the merge checkin to the same work items which were being used on the 10 changesets? Then you can consult the history of the work item to see whether it has been merged to the release or not. And if you make a build of the release branch then these items will be included in the associated work items list.

Personally I don't think it's a problem that some information is lost at this point. In our team merging to release branches is a very controlled process, in other words we know exactly what will be merged: bugfixes, changes, etc.

Gerrie Schenck
+1  A: 

At some point in the future you'll likely regret not using informative comments.

Even with extensive sets of changes commited to a branch in a single merge I'll painstakingly gather all of the commit messages and combine them into the branch commit.

It really doesn't take that long, and is really just a lot of copy pasting work, and you'll be glad you did in the future.

To further facilitate this you can use [a clipboard enhancing utility][1]. (I can hardly live without it now).

[1]: http://www.bluemars.org/clipx/"a clipboad enhancing utility"

Trampas Kirk