Thanks for the additional comments...

Jason - The free text area will actually associate the check in (commit) with the Work Item. In Visual Studio, when checking in, you can see all Work Items assigned to you and just select the appropriate Work Item from the list. We plan to implement something like this eventually, but for now, are you familiar enough with the Work Item IDs that you could just type the WI ID in manually instead of selecting from a list?

I hope this makes sense.

Hi,
I guess we expect the default behavior associated to code check-ins, allowing for a single or multiple WI and just associate or change the WI status.

A free text area is not enough as it does not allow an actual association in the work item history. This is the important part. I should be able to go back to a work item and see all the changesets that have been checked in against it. I should also be able to go to a changeset, and in reverse, see the work item it was checked in against.

A check in is typically associated to one work item in our company. I have never worked anywhere that would ever need a chageset to be checked in agaisnt multiple items, but I'm sure there is a need for someone out there to do it, so I don't know how definitive that answer really is.

Association is the main concern. Resolution can be done on the work item itself. However, VS does allow an association and will resolve the item at the same time if the user selects to do so. This would just be additional functionality that could be added - as long as the user has the option to select between the two.

This is not implemented in version 1, but is very high on our priority list.

This is a great product but all of our software check-ins in Visual Studio are goverened by TFS check-in rules including requiring a comment, work item association, and code reviewer. It would be great to be able to enforce these rules upon check-in in the future. Top priority would be work item association to add accountability for changes.

We definitely need this functionality but it goes further. We need it to comply with the policies in force for the project. eg. Checkin policies, associate with workitem policy.

We are looking at using RedGate source control with TFS. I agree this is a high priority for us too. We need the ability to maybe right click and see a view history, or do a diff with current version. We also need the need the ability to check in code against work items (just like Tortise SVN). So, if using DB Pro with VS, and you check in code, it will prompt you to select a work item. Also, should be a way to make comments mandatory. The reason we aren't using DB Pro is it does verification checks and never compiles our main project because of this (so that is an FYI why we need another solution).

Thanks for your reply. My guess is you are going to find almost all TFS users will at least want this functionality. The whole draw to TFS is the fact it does source control, version control, and change control. This feature is what integrates the source control and the change control in TFS for Visual Studio. I do understand that it's not the highest priority since everything should be working first, but I think it should be in the RTM.

I'm glad you can use the comment field for now. We're trying to get the basic source control functionality completed first. We are really curious to know how many TFS users need this functionality. Please vote/comment to help us prioritize what features we should work next.

Unlike the history and/or difference ideas being added to the interface which can still be checked in Visual Studio, this functionality can only be used if added to the interface directly. I believe this is a pretty important enhancement for most TFS users whi use if for Change Control as well. It already allows for a Comment on commit which is great (and which we'll use in the meantime to enter the TFS Work Item #), but an associated work item would be even better.