Traffic consumed by Team Foundation Server 2010

We are currently choosing version control and problem tracking software and are looking at Team Foundation Server 2010.

Some participants in our project often have a slow Internet connection (for example, while traveling), so it is important for us to have a source management system that does not consume too much traffic.

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

Does TFS 2010 support traffic compression ?

Are there other version control systems (such as SVN) that produce less or more traffic than TFS 2010?

+4
source share
2 answers

All traffic between the client (i.e. Visual Studio or Eclipse) and the server is highly compressed. Not only compressed source data using GZIP compression over the wire, but the actual data that is sent is optimized to send a minimum amount of data if necessary. This is true not only for the version control subsystem, but also for things like work item tracking and build automation.

TFS also supports the use of version control proxies on remote sites, which is useful if you have more than one team member working remotely from the same location as caching version control files at a remote location, ensuring that a specific version of the file needs to be uploaded Only by slow WAN link.

I'm afraid I don’t have hard numbers about how much bandwidth is required and how it compares with other version control systems. I would say that I used TFS in some high-bandwidth environments, and the performance was always very good, even when things like VOIP, Remote Desktop, or even browsing the Internet through the same connection did not give a good experience.

+4
source

TFS is very chat. Barebones checkin / checkout doesn't really matter, but once you start using it for problem management and workflow, it can become pretty serious. For example, some input elements on problem management screens may trigger server searches for each keystroke.

+2
source

Source: https://habr.com/ru/post/1308621/


All Articles