是否可以在不绑定到特定机器的情况下使用 TFS 工作空间？答案

【问题标题】：Can TFS workspaces be used without being tied to a specific machine?是否可以在不绑定到特定机器的情况下使用 TFS 工作空间？
【发布时间】：2010-03-25 19:13:17
【问题描述】：

所以我遇到了一个情况，我们有一个有 10 名开发人员的项目。每个开发人员当天进来时，都会随机分配一台机器用于当天的开发。机器名称不同，例如 DEV01 - DEV10。在将它们发布给开发人员时，机器是相同的，并且开发人员在白天所做的任何更改都不会保留在机器上（源代码更改存储在 TFS 中，而不是本地）。当然，这些实际上是虚拟机，但这与手头的问题并不真正相关。

问题是，每天早上，开发人员都会遇到 3 个问题：

1) 分配给他们的计算机可能不是他们最后分配给的同一台计算机。例如，DevMan A 可能昨天使用了 DEV04，今天收到了 DEV06。他的工作空间定义现在与 DEV06 相关联；他必须创建一个新的工作空间，或者将旧的工作空间迁移到 DEV04。

2) 分配给他们的机器可能昨天已经在使用，并且某些映射可能会发生冲突。例如，DevMan A 今天可能有 DEV04，并希望创建一个工作区，将项目文件夹映射到“C:\MyProj\Solution”。但是，DevMan B 昨天有 DEV04，他使用了相同的项目文件夹。 TFS 现在抱怨了。

3) 这可能是他们第一次在给定的机器上。他们现在需要为这台机器重新创建新机器的所有源代码控制映射。

所有这些问题都可以根据具体情况以简单的方式解决，但这确实会降低早上的工作效率。如果 TFS 工作区定义可以“宽松”，我们会更喜欢，这样它们就不会以某种方式在定义中包含机器名称。除此之外，如果有人知道上述问题的解决方案可以自动运行，或者在有限的用户干预下运行，那也是理想的。

【问题讨论】：

真正的答案是：不要这样做。解决方法是使用命令行调用为每台计算机设置工作区，并使用@Perica-Zivkovic 对映射文件夹的建议。
这是什么鬼生意？我认为这不利于编写好的代码，但如果它适用于您的团队，那就更好了！
@drachenstern：我知道这已经很晚了，但是出于安全原因，许多公司以这种方式运营承包商或离岸团队来管理非常流畅的资源。这是一个非常合法的设置。
@SV Hooligan ~ 好吧，当然，随便。我仍然认为将高质量的开发人员放在一个开放的牛棚中并每天对他们进行洗牌是迟钝的。以今天的存储价格，没有理由不能将开发环境固定在本地 SAN 中并将它们作为 VM 运行，为开发人员分配一个专用 VM。我想我不明白每天重新分配开发人员和工作站如何变成高效的环境。
@drachenstern：没有争论。

标签： visual-studio-2008 version-control tfs virtualization workspace

【解决方案1】：

首先，最明显的答案是将机器专用于用户。

其次...如果您真的想按照说明解决问题：

如果不将工作区分配给特定机器，您将无法使用它们。该假设隐含在产品中。但你可以骗它 :)
警告： 这个方法似乎有效，但我没有亲自运行过使用它的项目。

为每个用户分配一个“虚拟”机器名，即 UseridVM
对于每个虚拟机，需要进行以下（持久或脚本启动）设置：
- 创建一个新的环境变量“用户变量”，即 _CLUSTER_NETWORK_NAME_=UseridVM
很高兴拥有：使用专用于用户 ID 并映射（或使用脚本安装）到“D:”的虚拟硬盘驱动器，该驱动器跟随用户从 VM 到 VM。

现在，当用户打开 Visual Studio 时，工作区将使用指定的值“UseridVM”作为机器名称，因此每台机器上都会找到相同的工作区。

如果您没有永久虚拟硬盘驱动器，那么每个用户必须确保在一天开始时执行“真正的”“获取最新”（获取特定版本，选中所有框），因为工作区会记住什么文件已经下载，如果感觉它们已经存在就不会重新下载。

【讨论】：

那么 CLUSTER_NETWORK_NAME 是 TFS 识别为替代机器名称的环境变量吗？
是的。更具体地说，它被 Windows 操作系统识别为 HOSTNAME 的本地覆盖。 TFS 大概使用 HOSTNAME。
这似乎与启动时的脚本一起工作得很好，可以为每个用户设置环境变量。

【解决方案2】：

1.) 对于您要使用的每个工作站，您需要定义一个工作区（远程本地映射）。您可以将源文件存储在网络上（由于 VS 缓存，不建议这样做），但本地工作区（映射定义）需要存在于特定用户的特定 PC 上。

2.) 为每个开发人员创建单独的本地文件夹，以防止不同的人在同一个文件夹上工作并获取其他人的最新签出代码。例如：

c:\Projects\DevManA\...
c:\Projects\DevManB\... etc.

3.) 这可能会引起很多讨论，但我建议将 TFS 的根映射到本地工作区，例如。 DevManA 映射：

$/ to C:\Projects\DevManA\

然后，当您检查项目时，您将获得结构：

c:\Projects\DevManA\TFSProject1\..
c:\Projects\DevManA\TFSProject2\..
c:\Projects\DevManA\TFSProject3\..

等等

这是每个人都可以在 5 秒内完成的简单快速的映射，您就可以开始了。然后每个人在磁盘上都有相同的布局，就像在 TFS 中一样，这也更容易“适合大脑”。

【讨论】：

@Richard 这就是为什么我说它会引起讨论：D 在某种程度上是正确的，但实际上你会遇到并非所有开发人员都在处理所有 TFS 项目的情况（这是一个过滤器）。即使您正在从事一个大项目，良好的做法也是（再次引发讨论的危险：D）拥有开发人员分支+发布分支（另一个过滤器）并在您的开发人员分支中使用单独的解决方案来保持代码井井有条（另一个过滤器）。因此，在所有这些过滤器之后，开发人员每天工作一到两个解决方案，并且不需要“获得”更多。
没错，开发人员 通常不需要处理大型子树，但 TFS 不知道这一点。根据设计，除非您指定路径过滤器，否则所有 TFS 命令都针对整个工作区进行操作。如果您曾经忘记这样做，则副作用可能从混乱到服务器过载再到实际的正确性错误。例如：在检查分支 1 的小错误修复时，您不小心提交了一个大型的不完整变更集，该变更集在分支 2 中挂起（但共享相同的工作区）。我已经做到了:(

【解决方案3】：

我不知道这是否符合问题中所述的要求，但您可以查看一下：

http://blogs.msdn.com/granth/archive/2009/11/08/tfs2010-public-workspaces.aspx

TFS 2010 添加了公共/共享工作区，可供多个用户在同一台计算机上使用。

【讨论】：

【解决方案4】：

您可以将工作区放置在共享的网络驱动器上，这样开发人员登录的机器（虚拟或其他）都没有关系。这可以正常工作，但您还必须配置一些 COM 内容一次以使其满意。

【讨论】：

如果你在每台机器上将根绑定到（比如）P:\dev\users\my.name\tfs 一次，你就完成了。
文件可以在网络上，但需要为您正在使用的每台 PC 创建工作区
@Perica：没错。您必须在每台机器上绑定一次。