是否有人在地理分布的团队中使用 Team Foundation Server？我们在英国，尝试与澳大利亚的一个团队合作，我们发现这非常艰难。
我们主要的两个问题是：
许多像这样令人讨厌的小事情正在硬化我们的动脉，阻止我们交付代码，坦率地说，它们正在创造一种类似于将金色糖浆推上沙丘的用户体验。
有没有人每天都以这种方式使用 TFS 并取得（相对）成功？
如果是这样，您是否有任何值得了解的提示、提示、技巧或陷阱？
PS 升级到 CruiseControl.NET 不是一种选择。
绝对升级到 TFS 2008 和 Visual Studio 2008，因为它在各个方面都是 Team System 的“v2”版本。修复了许多中小型问题。
至于“随机签出的东西”，这几乎总是由于 Visual Studio 决定代表您编辑文件。尝试从 Team Explorer 获取最新信息，在 Visual Studio 中没有打开任何内容，然后查看该行为是否仍然存在。我敢打赌不会！
多个 TFS 服务器是个坏主意。确保您的代理配置正确，因为它会缓存重复的 GET。也就是说，TFS 是一个服务器连接模型，所以它总是比真正的“离线”源代码控制系统慢一点。
此外，如果您可以编辑您的问题以包含更具体的投诉或详细信息，那将有所帮助 - 现在它非常模糊，所以我不能很好地回答。
我们将 TFS 与一个有点分散的团队一起使用——它们离我们不太远，但通过一个缓慢且不可靠的 VPN 连接。
对于您的第一个问题，结帐时获取最新信息不是默认行为。（这里有一个解释）不过，有一个插件可以为你做这件事。
以下是适用于我们的工作流程：
[编辑] 好的，看起来你改写了这部分问题。是的，Jeff 是对的，VS 决定“为您”检查一些文件，例如 sln 和 proj 文件。它还会自动检查您编辑的任何源文件（这就是您想要的，对吗？尽管您可以在工具 > 选项 > 源代码控制中更改该设置）
代理显然需要一段时间才能加速（我们不使用它）但是一旦它缓存了大部分树，它应该很快。你能做一些监控并找到瓶颈吗？
除了获取最新的结账信息和速度之外，还有什么给您带来麻烦的吗？
据我了解，您可以在不同位置拥有多个 TFS 应用程序服务器。它们要么都可以与同一个 SQL Server 通信，要么您可以使用 SQL Server 镜像。拥有自己的本地 TFS 服务器可能会加快您的开发时间。