【问题标题】：Is it bad to use TFVC as an artifact repository for full releases?将 TFVC 用作完整版本的工件存储库是不是很糟糕？
【发布时间】：2016-10-11 16:11:59
【问题描述】：
我在一家公司工作，我们将来自大量不同应用程序的构建输出（工件，每个都来自不同的技术）存储到 TFVC 中，然后从我们的存储库到我们的环境服务器。我一直在研究工件存储库，以使我们不再使用 TFVC 来处理这些输出。在收集需求时，有人问我为什么要寻找替代方案。阅读TFVC的文档我发现了这个：
您可以使用 Team Foundation 版本控制 (TFVC) 从小型项目扩展到大型项目，并且通过使用服务器工作区，您可以扩展到非常大的代码库，每个分支包含数百万个文件和大型二进制文件。
我无法诚实地回答为什么我们应该使用工件存储库而不是 TFVC。它被命名为 Team Foundation Server 版本控制，而不是 Source Control。我们的部分要求是版本控制和备份。一旦我们完全自动化，我们将不需要这些存储库，但是，就目前而言，我们需要某种形式的版本化存储库来存储我们的工件。
所以我的问题是：
- 使用TFVC存储大量二进制文件是否不好
（构建输出）？
- 为什么要在 TFVC 上使用工件存储库？
【问题讨论】：
标签：
tfs
version-control
nexus
artifactory
tfvc
【解决方案1】：
当您将构建输出复制到放置/共享文件夹时。这会将构建输出在版本控制之外存储在 tfs 服务器数据库中。
至于使用 TFVC 存储大量二进制文件（构建输出）是否不好。一般来说，不管好坏，看你自己的需要。
在 TFS2012 上，您仍然可以将构建输出复制到源代码控制文件夹。所以这绝对是 TFVC 中的支持。
一些限制：如果您将构建输出放入源代码控制，这也意味着您的版本控制存储库会被文件（有时是大文件）堵塞。将文件添加到版本化存储库时，需要大量计算能力来计算版本和增量以及其他需要的东西，但对于放置文件夹，我们不需要这些。
更糟糕的是，当您想要删除旧文件时，您需要调用“destroy”命令，以确保不会让所有这些文件永远占用空间。
也可以看看这个博客：New un-versioned repository in TFS 2012
【解决方案2】：
除了空间/存储库膨胀问题之外，关键原因是版本控制。如果您为二进制文件创建（例如）NuGet 包，您可以安全地为不同的应用程序引用不同的版本，而不必担心在尚未针对最新版本的依赖项。举个例子：
你有 DependencyFoo，你把它变成了一个 NuGet 包。
应用程序 A 引用版本 1.0。
应用程序 B 引用版本 1.0。
为了支持应用程序 A，您对 DependencyFoo 包进行了一些更改。然后，您可以更新应用程序 A 引用的版本完全不会影响应用程序 B。
除此之外，如果您决定从 TFVC 过渡到 Git，Git 不能很好地处理二进制文件，当然也不应该将其包含在版本控制中。