最近在办公室，我们一直在谈论将大文件放入我们的 TFS 存储库。文件本身是 XML，大小通常为 100-200MB，有时大至 1GB。我们将它们用作自动化测试的数据，它们大多是静态的（大约每年都会进行一次小的调整）。无论如何，有一种观念认为将这样的文件放入存储库是不可以的，因为它们“大”，这会使事情“变慢”（在原始签入/签出之外），但我们并不真的有任何证据支持这一点。
所以我的问题是，将大型静态文件放入像 TFS（或 SVN、Git 等）这样的源代码存储库有什么优点/缺点/影响，可以吗？它会“填满服务器”还是产生其他可怕的后果？
【问题讨论】：
标签： version-control tfs
tl;dr：TFS 旨在优雅地处理大文件。您必须面对的最大障碍是上传/下载文件的网络带宽。第二个问题是服务器上的存储空间问题。假设您已经考虑了这两个问题，那么您应该没有任何其他问题。
网络带宽：签入或获取文件的开销很小，应该与典型的 HTTP 上传或下载一样快。如果您的客户端在网络方面远离服务器，他们可能会受益于在其本地网络上使用 TFS 源代码控制代理来加快下载速度。
请注意，与某些版本控制系统不同，TFS 在上传或下载新内容时不会计算和传输增量。也就是说，如果客户端有一个大文本文件的修订版 4，而修订版 5 在最后添加了几行，则某些版本控制工具会优化这种体验，只发送更改的行。 TFS 不做这个优化，所以如果你的文件经常变化，客户端每次都需要下载整个文件。
服务器存储：服务器上的磁盘空间相当简单 - 您需要足够的空间来保存文件，除此之外几乎没有开销。 TFS 不会因为您的存储库包含大文件而减慢速度。
如果这些文件经常被修改，您还需要考虑修订所使用的磁盘空间。 TFS 存储文件修订之间的“增量”——即两个版本之间的二进制差异。因此，如果文件内容在修订之间的变化很小，就像在文本文件的典型用例中那样，存储成本应该是便宜的。但是，如果整个内容发生变化，就像图像或 DLL 等二进制文件的典型情况一样，那么您将需要足够的磁盘空间来存储每个修订版。 （当然，您可以destroy以前的修订版以重新获得该空间。）
关于 TFS 中的增量的一个注意事项：为了减少签入时的开销，修订之间的增量不会立即计算，有一个每晚运行的后台“增量化”作业来计算增量以修剪空间。在那之前，每个修订都完整地存储在数据库中。因此，如果您有一个非常大的文本文件，并且每天都会进行大量修订，那么您的磁盘空间需求将需要考虑到这一点。
客户端存储：客户端还需要有足够的磁盘空间来包含这些文件（尽管仅限于他们下载的修订版）。这可以在您的工作区映射中得到缓解，这样如果不需要大文件，则会隐藏（或不包含在您的工作区中）。
警告：获取历史版本：如果您发现自己经常请求大文件的历史版本（例如：我想要一个 ISO 映像 7 年前的变更集），那么您将制作服务器应用增量链回到那个版本。如果您有多个客户端同时执行此操作，这可能会占用您的内存。
【讨论】：
如果这些文件不断变化并且它们的增量很大，我最终会预计整体 TFS 性能会受到影响。
您明确表示情况并非如此，因此，前提是您的 SQL 服务器有容量来容纳存储，我相信您应该能够继续进行而不会产生任何影响。
您可能会遇到的一个小缺点是，当您正在构建新的工作区时，您必须在其中提取这些文件从他们的存储库中。不幸的是，在 TFS 构建期间也会发生这种情况，因此您的构建现在可能需要更长的时间。这个角度的严重程度很大程度上取决于您的网络星座/稳定性。
【讨论】：
您将遇到的最大问题（不便）是必须将这些海量文件下载到您的所有工作区，或将它们映射出来。考虑将它们放入一个单独的团队项目中以使其更容易（除非您想将它们包含在分支中，在这种情况下，我会滥用将所有内容都放在一个团队项目中）
如果您可以控制 xml 格式，那么还可以考虑进行一些调整以使其更小。这将提高存储/获取操作的性能以及加载速度...缩短元素和属性名称，减少为浮点数输出的小数位数等。您会发现像这样的简单方案会敲很多兆字节减少 Gb 大小的文件的大小，并且很容易敲出快速 xslt 转换或代码以将文件快速转换为新格式。
【讨论】：