Don't get me wrong; I think that TFS is a great product but, moving forward, this would be my wish list for the following TFS version, codename Rosario.
- Server Side Check-in policies
Checkin policies are a very nice feature in TFS; for example you can enforce that before anyone checks a changeset in, he has to associate it with a Work item, or he's had to build the solution and run FxCop, etc... The concept is good, but I don't like the way that it has been implemented: Checkin policies are enforced at client side rather than at server side and this has some bad implications, for example the inconvenience of deploying custom checkin policies.
TFS explorer comes along with some policies but as you may have expected you can create your own custom policies; actually you might want to check the policies that TFS 2008 Power tools provides before creating a new one.
So far so good, the catch is that after getting one way or another your custom policy, in order to enforce it, you have to make sure that everyone in your team deploys it in his workstation or it won't be run when they check in and, on top of that, they will get a nasty policy loading error :( As you can see here, there are people out there that have the same frustration...
I've been focusing in the inconvenience of deployment that this client-side model implies, but what about security? So what if a developer decides to change any of the policies implementation to disable check-in validation?... Well, you might be wondering why somebody would want to do that, but if check-in policies were enforced at server side you wouldn't be wondering.
- TFS application tier running in a 64bit box
There is not much to say about this, the header text is self explanatory :)
Even if you go for a non single server deployment where you could use a x64 for the data tier (SQL Server), TFS application tier still needs to be installed in a x32 bit machine.
- Branching: carry source history to the branch
As Brendan Lawlor pointed out here, when a branch is created in TFS 2005, its history starts from its creation point of time so the branch doesn't "remember" any of the changes that were made on its source.
This means, for example, that comparing a changeset from the branch against a change made back in time on the head becomes a non straightforward task, especially if you happen to be in a situation where nested branches are required.
Unfortunately, after a simple test in TFS 2008, you will notice that this problem hasn't been solved yet.
- TFS event subscription GUI tool
It would be great if TFS came along with a proper GUI tool to handle subscriptions for events remotely, something like this open source tool provides but not only limited to work item events.
Even for something so simple like sending a notification email when a build fails the TFS Project Alerts screen is useless so you have to end up using the bissubscribe command tool, which by the way can only be run locally on the TFS application server.