version-control - 源代码管理 (TFS) 中的大文件

Question

最近在办公室，我们一直在谈论将大文件放入我们的 TFS 存储库。文件本身是 XML，大小通常为 100-200MB，有时大到 1GB。我们将它们用作自动化测试的数据，而且它们大多是静态的(每年左右都会进行一次小调整)。无论如何，有一种观点认为将这样的文件放入存储库是不可以的，因为它们“大”并且会使事情“变慢”(在原始 checkin / checkout 之外)，但我们实际上并没有有任何证据支持这一点。

所以我的问题是，将大型静态文件放入像 TFS(或 SVN、Git 等)这样的源代码存储库的利弊是什么？它会“填满服务器”还是有其他一些可怕的后果？

Answer 1

tl;博士 :TFS 旨在优雅地处理大文件。您必须面对的最大障碍是上传/下载文件的网络带宽。第二个问题是服务器上的存储空间。假设您已经考虑了这两个问题，那么您应该没有任何其他问题。

网络带宽: checkin 或获取文件的开销很小，它应该与典型的 HTTP 上传或下载一样快。如果您的客户端远离服务器，在网络方面，他们可能会受益于在其本地网络上安装 TFS 源代码控制代理以加快下载速度。

请注意，与某些版本控制系统不同，TFS 在上传或下载新内容时不计算和传输增量。也就是说，如果客户端有一个大文本文件的修订版 4，而修订版 5 在末尾添加了几行，一些版本控制工具会优化这种体验，只发送更改的行。 TFS 没有做这个优化，所以如果你的文件经常变化，客户端每次都需要下载整个文件。

服务器存储:服务器上的磁盘空间相当简单 - 您需要足够的空间来保存文件，除此之外几乎没有开销。 TFS 不会因为您的存储库包含大文件而减慢速度。

如果这些文件被频繁修改，您还需要考虑修订所使用的磁盘空间。 TFS 存储文件修订之间的“增量” - 即两个版本之间的二进制差异。因此，如果文件的内容在修订之间的变化很小，就像在文本文件的典型用例中一样，存储成本应该很低。但是，如果整个内容都像图像或 DLL 这样的二进制文件一样发生了变化，那么您将需要足够的磁盘空间来存储每个修订版。 (当然，您可以 destroy 以前的修订版以重新获得该空间。)

关于 TFS 中的增量的一个注意事项:为了减少 checkin 时的开销，不会立即计算修订之间的增量，有一个后台“增量化”作业每晚运行以计算增量以修剪空间。在此之前，每个修订版都完整地存储在数据库中。因此，如果您有一个非常大的文本文件，并且每天都在进行大量修订，则您的磁盘空间需求将需要考虑到这一点。

客户端存储:客户端也需要有足够的磁盘空间来包含这些文件(尽管仅在他们下载的修订版中。)这可以在您的工作区映射中得到缓解，以便隐藏大文件(或以其他方式不包含在您的工作区中)如果他们不需要。

警告:获取历史版本:如果您发现自己经常请求大文件的历史版本(例如:我想要七个变更集之前的 ISO 镜像)，那么您将让服务器应用增量链以返回到该修订版。如果您有多个客户端同时执行此操作，这可能会占用您的内存。