Monday, July 7, 2008

TFS wish list

I've been using TFS 2008 for a while, and despite the new good features (easier installation, offline support, better build management, built-in continuous integration, etc), I'm a little bit disappointed to see that some limitations existent in the previous TFS 2005 haven't been solved yet in this new release.
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.
  1. 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.

  2. 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.

  3. 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.

  4. 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.
That was my list; feel free to post your own thoughts and comments about it.

kick it on DotNetKicks.com

5 comments:

  1. hi Javi,
    what about branch history when you merge back. I think it was kinda lost in tfs 2005, well not really lost but I'm not keen on digging in older branches. I can imagine that hasn't been fixed either.
    Good post!
    Cheers,
    Mihailo

    ReplyDelete
  2. Hi Mihailo,

    Indeed there is no fun tracking down changes in such a situation. I'm not sure though, about carrying history changes from the branch to the head because maybe you don't want to see potential intermediate changes that happened in the branch reflected into its source history.

    Thanks!

    Javi

    ReplyDelete
  3. Yes, you're right, I don't want them always, but I want them sometimes. Maybe we're just not using TFS as it should be used ... hmmm another good question :)

    Cheers,
    Mihailo

    ReplyDelete
  4. It would have been good to be provided a different option like "show branching history" . Merging is a nightmare if you can't know that is changed when.

    Great post btw, I hope big brother hears us :)

    ReplyDelete
  5. "TFS event subscription GUI tool" - well, you can have one here: http://www.teamalertsmanager.com/Download.aspx (30-days full-functional trial available). It started as internal project, just because TFS built-in subscription management is pretty useless for anything but the very simple tasks. Our web-application capable of evaluating a complex expressions for any type of e-mail notification you wish to create. We greatly appreciate your opinion and feedback, so feel free to connect with us.

    ReplyDelete