Working at Microsoft we had a checkin policy, that you can't checkin without associating the changeset with a work item. Never really occured to me, why we had to do this, but it seemed like a good practice.
On the last two projects I worked on, that involved Team Foundation Server as version control, the customer has been using other software for bug tracking. Because of that, we haven't used workitems, and it seems like there's no point in associating changesets to workitems.
That was a wrong assumption. After I completed the first task on the project I'm currently working on I discovered, that it is a requirement that we create a document, describing every change that's been done to the code. The document is meant for code review, so it's a fairly good idea. But - when I had to track down every change done in the repository for 14 days of work, and 20 other developers made checkins, it showed to be a bit of a task to track down my changes (and boring as well).
On the next task, we decided to create a workitem. Not that it'll be used by anybody else. But we decided to create it, and agreed to associate every checkin with the workitem, so that it'll be a piece of cake to list the changesets regarding this task.
Now this seems like a pretty good solution to me. This way we can always track down every change done, regarding this task. But is it without problems? I don't think so. First of all, it requires some discipline from the developers to do the association. I've seen too many developers who doesn't even bother to write a comment, when they checkin. Another problem on the current project is, that there hasn't been awareness of the details in the code review document, until everybody completed a task which typically lasted 2-4 weeks. So what can you do, when it's too late ?
The best solution I found so far, to track down your own changes is to install the "Team Foundation Server Power Tools" which can be found here: TFS powertools .
You'll get lots of small extra stuff in you're team explorer. One thing is, that you'll get a node in the treeview displaying your team members. On the team members node you can get a list of every changeset that's been done by a specific developer, hence help you do the code review.
Big brother? Maybe, but very helpfull.
Update 20090424: Erik Ejlskov told me about a tool for doing extended searches in the repository called "Team Foundation Sidekicks". Pretty cool 3rd party tool, can be downloaded here: Team Foundation Sidekicks
Subscribe