将TFVC用作完整版本的工件存储库是不是很糟糕？

Question

我在一家公司工作，我们将构建输出（工件，各自来自各种技术）从大量不同的应用程序存储到TFVC，然后从我们的存储库存储到我们的环境服务器。我一直在调查工件存储库，让我们不再使用TFVC来实现这些输出。在收集要求的同时，我被质疑为什么要研究替代方案。阅读TFVC的文档我发现了这个：

  

您可以使用Team Foundation版本控制（TFVC）从小型项目扩展到大型项目，并且通过使用服务器工作区，您可以扩展到非常大的代码库，每个分支和大型二进制文件包含数百万个文件。

我无法诚实地回答为什么我们应该在TFVC上使用工件存储库的问题。它命名为Team Foundation Server 版本控制，而不是源代码管理。我们的部分要求是版本控制和备份。一旦我们完全自动化，我们就不会需要这些存储库，但是，就目前而言，我们需要某种形式的版本存储库来存储我们的工件。 所以我的问题是：

• 使用TFVC存储大量二进制文件是不是很糟糕 （建立输出）？
• 为什么我要在TFVC上使用工件存储库？

Answer 1

将构建输出复制到删除/共享文件夹时。这将在版本控制之外存储构建输出，但在tfs服务器数据库中。

至于使用TFVC存储大量二进制文件（构建输出）是不好的。一般来说，无论好坏，都可以根据您的需要而定。

在TFS2012上，您仍然可以将构建输出复制到源控制文件夹。所以这肯定是TFVC的支持。

一些限制：如果将构建输出放入源代码控制中，这也意味着您使用文件和有时大文件阻塞了版本控制存储库。当文件被添加到版本化存储库时，有很多计算能力用于计算版本和增量以及其他需求，但对于drop文件夹，我们不需要这些。

更糟糕的是，当你想删除旧东西时，你需要调用“ destroy ”命令，以确保你不会让所有这些文件永远占用空间。

另请查看此博客：New un-versioned repository in TFS 2012

Answer 2

除了空间/存储库膨胀问题之外，关键原因是版本控制。如果您为二进制文件创建（例如）NuGet包，则可以安全地为不同的应用程序引用不同的版本，而不必担心在未经过测试的应用程序中引入问题（无论是错误还是编译错误）的更改最新版本的依赖项。举个例子：

你有DependencyFoo，你变成了NuGet包。

应用程序A引用版本1.0。

应用程序B引用版本1.0。

为了支持应用程序A，您需要对DependencyFoo程序包进行一些更改。然后，您可以更新应用程序A 引用的版本，而不会影响应用程序B 。

除此之外，如果您决定从TFVC过渡到Git，Git不能很好地处理二进制文件，并且理所当然不应该包含在版本控制中。