最近在辦公室，我們一直在討論將大文件放入我們的TFS存儲庫。這些文件本身就是XML，通常爲100-200MB，有時甚至可以達到1GB。我們將它們用作自動化測試的數據，並且它們大多是靜態的（每年都會進行微調）。無論如何，有一種觀點認爲將類似這樣的文件放入存儲庫是一種禁忌，因爲它們很「大」，並且會讓事情變得「緩慢」（在原始簽入/簽出之外），但我們並不真正有任何證據支持這一點。源文件控制（TFS）中的大文件
所以我的問題是，將大型靜態文件放入類似TFS（或SVN，Git等）的源代碼庫中的優點/缺點/含義是否可行？它會「填滿服務器」還是會有其他可怕的後果？
tl; dr：TFS旨在優雅地處理大文件。您必須面對的最大障礙是上傳/下載文件的網絡帶寬。第二個問題是服務器上的存儲空間。假設你已經考慮了這兩個問題，你不應該有任何其他問題。
網絡帶寬：檢查或獲取文件的開銷很小，它應該像典型的HTTP上傳或下載一樣快。如果你的客戶端遠離服務器，在網絡方面，他們可能受益於在他們的本地網絡上有一個TFS源代碼控制代理來加速下載。
請注意，與某些版本控制系統不同，TFS在上傳或下載新內容時不計算和傳輸變化量。也就是說，如果客戶端具有大型文本文件的版本4，並且版本5在最後添加了幾行，則一些版本控制工具優化了這種體驗以僅發送更改的行。 TFS不會執行此優化，因此如果您的文件頻繁更改，客戶端將需要每次下載整個文件。
服務器存儲：服務器上的磁盤空間相當簡單 - 您需要足夠的空間來存放文件，除此之外幾乎沒有額外的開銷。 TFS不會因爲您的存儲庫包含大文件而放慢速度。
如果這些文件經常被修改，您還需要考慮修訂版所使用的磁盤空間。 TFS在文件修訂版之間存儲「deltas」 - 即兩個版本之間的二進制差異。因此，如果文件內容在典型使用情況下與文本文件之間的修訂間的變化最小，則存儲成本應該便宜。但是，如果整個內容會像二進制文件（如圖像或DLL）那樣變化，那麼您將需要足夠的磁盤空間來存儲每個修訂。 （當然，你可以通過destroy以前的版本來重新獲得這個空間。）
關於TFS中deltas的一個注意事項：爲了減少在簽入時間的開銷，修訂之間的增量不是立即計算的，有背景「 deltafication「作業每晚運行以計算修訂空間的變化量。在此之前，每個修訂都完整地存儲在數據庫中。因此，如果每天都有大量修訂版本很大的文本文件，則您的磁盤空間需求將需要考慮到這一點。
客戶端存儲：客戶需要有足夠的磁盤空間也包含這些文件（雖然只在他們已經下載的版本。）你可以在你的工作空間的映射得到緩解，使得大型文件是隱形（或者不包括在你的工作區中），如果他們不需要的話。
警告：獲取歷史版本：如果你發現自己要求的大文件的歷史版本頻繁（例如：我想一個ISO鏡像7次變更前），那麼你打算讓服務器應用增量鏈回到那個版本。如果您有多個客戶同時進行此操作，這可能會導致您的記憶力下降。
如果這些文件不斷變化&他們的三角洲是大的，我最終會期望在總體TFS性能的懲罰。
您明確聲明，事實並非如此，所以，只要您的SQL服務器具有容納存儲的能力，我相信您應該可以繼續操作而不會有任何影響。
您可能會遇到的一個小缺點是當您構建新的工作區時，您將不得不從存儲庫中提取這些文件。不幸的是，這在TFS構建過程中也會發生，因此您的構建可能需要更長的時間。這個角度的嚴重程度很大程度上取決於你的網絡星座/穩定性。
OP指定他試圖揭開這些觀點的原因 - 你能解釋爲什麼你會期望表現會受到懲罰嗎？ – bwerks
您將遇到的最大問題（不便）是必須將這些大量文件下載到您的所有工作區，或將它們映射出去。考慮將它們放入一個單獨的團隊項目中，以使其更容易（除非您希望將它們包含在分支機構中，在這種情況下，我會濫用將所有內容保存在一個團隊項目中）
如果您控制了xml格式，考慮一些調整，使他們更小。這可以提高存儲/獲取操作的性能，並且還可以加載速度...縮短元素和屬性名稱，減少輸出浮點數的小數位數等。您會發現像這樣的威脅簡單方案會敲幾百兆字節取消Gb大小文件的大小，並且很容易就可以快速完成xslt轉換或將代碼快速轉換爲新格式。
啊，這是非常棒的，確實是完整的信息。我認爲TFS將是最好的選擇，因爲我們現在正在做的是不斷地從網絡位置訪問文件，由於上面提到的帶寬原因，這些文件需要FOREVER。 –
要添加的一件事，對於16 MB以上的文件禁用afaik分離（對於您的情況，這是真實的）。我在http://blogs.msdn.com/b/billheys/archive/2011/05/05/how-tfs-stores-files-and-calculated-deltas-on-versioned-files.aspx發現了關於它的信息。 – MichalMa
@MichalMa：好點，我完全忘記了這一點。 –