A.R*_*.R. 16 version-control tfs tfs2010
最近在办公室,我们一直在谈论将大文件放入我们的TFS存储库.这些文件本身就是XML,通常大小为100-200MB,有时甚至大到1GB.我们将它们用作自动化测试的数据,它们大部分都是静态的(每年左右进行一次小调整).无论如何,有一种想法是将这样的文件放入存储库是一个禁忌,因为它们"很大"并且会使事情变得"慢"(在原始登记/退出之外)但我们并不是真的有任何证据支持这一点.
所以我的问题是,将大型静态文件放入源代码存储库(例如TFS(或SVN,Git等)的优点/缺点/含义是否可以？它会"填满服务器"还是会产生其他可怕的后果？
Edw*_*son 28
tl; dr:TFS旨在优雅地处理大型文件.您必须面对的最大障碍是上传/下载文件的网络带宽.第二个问题是服务器上的存储空间.假设您已经考虑过这两个问题,那么您不应该有任何其他问题.
网络带宽:签入或获取文件的开销很小,应该与典型的HTTP上传或下载一样快.如果您的客户端远离服务器,从网络方面来说,他们可以通过在本地网络上安装TFS源代码控制代理来加速下载.
请注意,与某些版本控制系统不同,TFS在上载或下载新内容时不会计算和传输增量.也就是说,如果客户端具有大型文本文件的修订版4,并且修订版5在末尾添加了几行,则某些版本控制工具会优化此体验以仅发送更改的行.TFS不进行此优化,因此如果您的文件经常更改,客户端将需要每次都下载整个文件.
服务器存储:服务器上的磁盘空间非常简单 - 您需要足够的空间来容纳文件,除此之外几乎没有开销.TFS不会因为您的存储库包含大文件而变慢.
如果经常修改这些文件,您还需要考虑修订所使用的磁盘空间.TFS在文件修订之间存储"增量" - 即两个版本之间的二进制差异.因此,如果文件的内容在修订之间的最小变化(如典型的文本文件用例),则存储成本应该很低.但是,如果整个内容发生变化,就像图像或DLL这样的二进制文件一样,那么您将需要足够的磁盘空间来存储每个版本.(当然,您可以通过destroy以前的修订来重新获得该空间.)
关于TFS中的增量的一个注释:为了减少登记时的开销,修订之间的增量不会立即计算,有一个后台"deltafication"作业,每晚运行以计算调整空间的增量.在此之前,每个修订版都完整地存储在数据库中.因此,如果您有一个非常大的文本文件,每天都会进行大量修订,那么您的磁盘空间要求需要考虑到这一点.
客户端存储:客户端还需要有足够的磁盘空间来包含这些文件(尽管只是在他们下载的版本中).这可以在工作区映射中减轻,以便大文件被隐藏(或者不包含在如果他们不需要你的工作区.
警告:获取历史版本:如果您发现自己经常请求大型文件的历史版本(例如:我之前想要一个ISO映像七个更改集),那么您将使服务器应用增量链以返回到该修订版本.如果您有多个客户端同时执行此操作,则可能会对您的内存造成负担.