Traffic consumed by Team Foundation Server 2010

4
votes

We are currently selecting a source control and issue tracking software, and are looking towards Team Foundation Server 2010.

Some participants of our project often have slow Internet connection (for example during travel), and therefore it is important for us to have a source control system that does not consume too much traffic.

I was unable to find information on traffic consumption when using TFS 2010. Does anyone has such info?

Does TFS 2010 support traffic compression?

Do other source control systems (like SVN, for example) produce less or more traffic than TFS 2010?

2
tfs
Will you have to deal with having no internet at all while travelling? – Lasse V. Karlsen
Im not sure TFS was ever built for the interwebz, 2010 may be different but I doubt it. – James Westgate

2 Answers

4
votes

All traffic between the client (i.e. Visual Studio or Eclipse) and the server is highly compressed. Not only is the raw data compressed using GZIP compression over the wire, but the actual data that is sent is optimized so that the minimal amount of data is sent when required. This is true not just for the version control sub-system but also things like work item tracking and the build automation system.

TFS also supports the use of a version control proxy server at remote sites which is useful if you have more that one team member working remotely from the same location as this will cache version control files out at the remote location ensuring that a particular version of a file only needs to be downloaded once over the slow WAN link.

I'm afraid I do not have any hard numbers about how much bandwidth is required and how this compares to other version control systems. I would say that I've used TFS in some very bandwidth challenged environments and performance has always been pretty good even when things like VOIP, Remote Desktop or even web browsing over the same connection have not been giving a good experience.

2
votes

TFS is very chatty. Barebones checkin/checkout is not a big deal, but once you start using it for issue management and workflow it can get pretty serious. For example, some of the input elements on the issue management screens can trigger server lookups per keystroke.