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