VSTS/TFS performance

Ayende Rahien, the creator of RhinoMocks, has an interesting blog post in which he talks about the troubles he’s had with TFS, and he advises people to avoid it:

 

Latency is a killer here, TFS has a always connected model, which means that it drives me crazy when I want to edit several files, it checks them out, one by one, s l o o o o w l y.
Then there is read-only bit – plays havoc with my build process.

I found the merge capabilities quite week, frankly.
Patching doesn’t exists, so you are forced to do work around that with shelving, with you can’t send in an email, etc.
No good offline support.

I ended up chatting with him and we discussed what his perception was. In a nut shell it was:

• No offline support
• Checking out a file to edit it is slow
• Using a refactoring tool which has to do multiple checkouts is very slow
• Patching support is non-existant (for example, against repositories you don’t have permissions to)
• Opening a source controlled project takes a long time
• Merging is weak

The funny thing was, I haven’t seen a source control integration yet which doesn’t have some latency when editing a file that hasn’t been checked out, and then has to be. We used Subversion for quite a while (because I fought hard against VSS and won), and we started out with the SVN MSSCCI provider. Even though SVN is not a connected system – meaning checkouts are basically just marking the file writable – there still was a little bit of latency if I just started typing on a file I hadn’t checked out for edit.

After talking with him, it seems as though he isn’t using an integrated SCM, but doing it outside the IDE (ala TortoiseSVN, which we ultimately ended up going to). That’s going to be hard to compete with, since the IDE doesn’t have to do anything.

However, I understand what he is saying about performance problems. One option could be just to always keep everything checked out, and use the multiple check-out option. Of coursem that doesn’t help with the opening project issue – I ran a sniffer as I opened a project that was version controlled and caught at least 20k worth of traffic before the project opened. I understand why it is doing that (mainly for various enterprise-y type features), but can also see how devs who are used to things being snappier would not be happy (I wouldn’t be).

Nor does it help with offline support. That story is still awful, although I know the team is working on it.

With merging – James Manning has a post on customizing the merge tools in TFS which should help.

Finally, the concept of patching is an interesting one. I know that work I’ve done on NUnit in the past was that way – I’d sync my sources, make my changes, and then send a patch up to be approved, since I didn’t have direct check-in abilities. Granted TFS has shelvesets, but I’m still going to run that past the VSTS team to see what they think of it.

So, thanks to Ayende for holding a good conversation back and forth about the things he saw (he isn’t using TFS anymore). Hopefully the product will get back to the point where agile developers can be just as productive using TFS as no intergrated provider.