tfs - 在 Team Foundation Server 中实际使用 Mercurial？

Question

我的商店使用 TFS，除了缺少本地存储库提交/恢复之外，通常对它很满意。我开始自己在本地使用 Mercurial 来帮助管理较小的更改块，然后将它们发布到 TFS。如果中央 VCS 是 Subversion，我看到 Subversion 有一个“桥”组件可以自动启用它。我还没有为 Team System 找到一个。这让我感到鼓舞的是，其他人已经走上了将 DVCS 与 CVCS 系统集成的这条道路。

(1) 有人知道吗？我有点怀疑它(快速搜索没有找到任何东西)。

(2) 有人以这种方式使用 Mercurial/TFS 吗？ 如果是这样，你能不能分享你的经验。我特别想了解在通过 Mercurial 进行重大事件后可能会出现哪些关于 TFS 提交的问题并不明显。

到目前为止，只有我使用 if 几天，这似乎是一个全面的双赢——但我知道的足够多，认为这就是那么容易。

Answer 1

不确定这是否是您还不知道的事情，但我已经在本地使用 mercurial 一段时间了，到目前为止，我认为好处超过了管理两个源代码控制系统的额外开销。这是我一直在做的事情:

我让我的 TFS 结帐成为一个 HG 存储库，我认为它是我的“主人”。我从 TFS 获取更新并将它们提交到这个 repo，所以它包含来自 TFS 的项目的最新状态。这里重要的是，没有独立于 TFS 更新或 Hg 合并(这是第 2 部分)的任何更改

任何时候我需要进行更改时，我都会克隆我的“主”存储库并在那里完成我的工作。我发现每个功能或故事的克隆实际上很容易管理，而且感觉很干净。完成一个功能后，我将 Hg 合并回“主”存储库，该存储库已应用所有 TFS 更新。这让我可以使用 Mercurials 合并功能，它远远优于 TFS，以至于质疑 TFS 如何声称合并代码。合并完成后，我将其提交到 Hg，然后将这些更改检查到 TFS。最好的部分是，当我 checkin 到 TFS 时，我不需要合并任何东西。非常非常棒。

现在，这是我用这种方法发现的问题:

最大的事实是 TFS 在发现变化方面很糟糕。有一个make writable插件，您可以使用它使修改后的文件在 Mercurial 更新/合并时可写。为此，我找到了两个选项。您可以强制 TFS 脱机，此时它会假设需要 checkin 任何可写的内容，或者您​​可以使用源代码控制工具中的比较工具并选择更改的文件并单独 checkout 它们。两者都是蹩脚的 IMO

源代码控制绑定(bind)仍然存在于项目级别，即使您从 hg 存储库中排除了 TFS 源代码控制文件(您应该这样做)。在您将文件添加到解决方案之前，这并不完全明显，此时它会尝试将其添加到源代码管理中。您可以“撤消挂起的更改”并摆脱源代码管理添加，但这真的很烦人。

好消息是，我使用这种方法完成了一个相当大的合并，我认为如果我被迫使用 TFS 工具来完成它，我认为这会导致我转向某种形式的硬毒品。

我尚未将此应用于更新 TFS 中的分支，但我的猜测是它会比您在 TFS 中提供的合并选项要好得多。在相关说明中，由于您可以一次 checkin 工作功能块，因此使用 TFS 合并的问题会更少，因为功能所需的所有更改都集中在一个地方。

我没有尝试解决的一件事是在整个团队中分享这一点。部分原因是它真的不必是一个团队范围的事情。我远程工作，因此拥有本地存储库很重要，并且可以节省大量时间。我的开发团队的其他成员可能会也可能不会从这种方法中获得同样的好处，但我发现我可以在不影响他们工作方式的情况下非常酷。

更新
一段时间以来，我一直想根据评论和我使用大型 TFS 存储库的一些经验，使用其他信息更新此响应。

首先作为@ Eric Hexter在评论中指出，您可以使用 rebase extension更好地将您工作存储库中的提交集成到您的主 TFS 存储库中。但是，根据您希望提交在 TFS 中的显示方式，您可能需要使用 collapse extension将您的更改压缩到单个提交中(这可以使 TFS 中的回滚更容易)。还有来自 TFS PowerTools 的“在线”命令这可以使让 TFS 知道发生了什么变化的工作更容易(再次感谢 Eric 在他的 blog post 中提到这一点)

现在，当我最初写这篇文章时，我正在开发一个只有一个 TFS 分支的项目，开发人员正在使用它，而且相当小，所以克隆存储库没什么大不了的。后来我发现自己在一个项目中工作，该项目的存储库在结帐后大约为 1.5GB，在构建后要大得多，并且经常涉及在 TFS 中的分支之间切换。显然，这种方法不太适合这种环境(特别是因为在某一时刻不可能在任意目录中构建解决方案。

最好使用类似于 gits 主题分支的技术来处理大小问题，而不是将存储库克隆到新目录。对此有几种选择。我认为最好的实际上是使用 bookmark extension并创建主题“书签”而不是主题分支。您也可以使用命名分支，但它们具有永久性的轻微缺点，并且可以与您可能做的任何克隆一起旅行(如果您想与同事分享您漂亮的 TFS-Hg 混合)。书签在你的仓库中是本地的，并有效地指向一个提交和随头旅行。它们被实现，以便它们可以在 Hg 期望修订的任何地方使用(因此合并、更新等)。您可以使用这些来创建一个 TFS 书签作为您的主要“分支”，它只从 TFS 获取更新，并从主题工作合并，每个主题都有自己的书签，一旦提交回 TFS，您就可以删除。如果您更愿意使用命名分支，那么您可以应用完全相同的技术，这很方便。

现在，多分支问题更加棘手，尤其是因为 TFS“分支”实际上是原始分支中每个文件的副本，这意味着每次从 TFS 拉入分支时，您的存储库都会变得更大。解决此问题的一种可能方法是使用命名的 Hg 分支和书签的组合，这样您就可以为每个 TFS 分支创建一个分支，然后从这些分支为您的工作创建书签。这些场景中真正令人头疼的是通过所有这些来处理 TFS 工作区。您可以删除工作区中的映射并获得很多，但是一旦您映射回您的工作目录，您就必须小心 TFS 踩踏文件(这实际上是 TF PowerTools 派上用场的地方)。试图让工作区保持连接，而你的切换分支很快就会变得丑陋。 Hg purge extension 是您工具带中很不错的几个工具。和 TF PowerTools“scorch”命令。两者都有效地删除了不在版本控制中的文件(技术上“scorch”确保 TFS 和您的本地工作目录匹配，因此它也可以更新文件)。

然而，对我来说，这个过程变得非常繁重且容易出错。我最近改用 git 和 git-tfs ，因为它为我管理 TFS 工作区，并消除了与该方面相关的许多负担。可悲的是，任何地方似乎都没有“hg-tfs”，或者我可能会选择它。