MS Team Foundation Server in distributed environments - hints tips tricks needed

Question

Is anyone out there using Team Foundation Server within a team that is geographically distributed? We're in the UK, trying work with a team in Australia and we're finding it quite tough.

Our main two issues are:

1. Things are being checked out to us without us asking on a get latest.
2. Even when using a proxy, most thing take a while to happen.

Lots of really annoying little things like this are hardening our arteries, stopping us from delivering code and is frankly creating a user experience akin to pushing golden syrup up a sand dune.

Is anyone out there actually using TFS in this manner, on a daily basis with (relative) success?

If so, do you have any hints, tips, tricks or gotchas that would be worth knowing?

P.S. Upgrading to CruiseControl.NET is not an option.

Answer 1

Definitely upgrade to TFS 2008 and Visual Studio 2008, as it is the "v2" version of Team System in every way. Fixes lots of small and medium sized problems.

As for "things being randomly checked out" this is almost always due to Visual Studio deciding to edit files on your behalf. Try getting latest from the Team Explorer, with nothing open in Visual Studio, and see if that behavior persists. I bet it won't!

Multiple TFS servers is a bad idea. Make sure your proxy is configured correctly, as it caches repeated GETs. That said, TFS is a server connected model, so it'll always be a bit slower than true "offline" source control systems.

Also, if you could edit your question to contain more specific complaints or details, that would help -- right now it's awfully vague, so I can't answer very well.

Answer 2

We use TFS with a somewhat distributed team - they aren't too far away but connect via a slow and unreliable VPN.

For your first issue, get latest on checkout is not the default behaviour. (Here's an explanation) There is an add-in that will do it for you, though.

Here's the workflow that works for us:

1. Get latest
2. Build and verify nothing's broken
3. Work (changes pended)
4. Get latest again
5. Deal with merge conflicts
6. Build and verify nothing's broken
7. Check in

[edit] OK looks like you rephrased this part of the question. Yes, Jeff's right, VS decides to check some files out "for you," like sln and proj files. It also automatically checks out any source file that you edit (that's what you want though, right? although you can change that setting in tools > options > source control)

The proxy apparently takes a while to get ramped up (we don't use it) but once it has cached most of the tree it's supposed to be pretty quick. Can you do some monitoring and find the bottleneck(s)?

Anything else giving you trouble, other than get-latest-on-checkout and speed?

Answer 3

From my understanding you can have multiple TFS Application servers in different locations. They either can both talk to the same SQL Server or you could use SQL Server mirroring. Having your own local TFS server would likely speed up your development times.