有時我們的項目樹可以有二進制文件，如jpg，png，doc，xls或pdf。只有二進制文件的一部分被更改時，GIT，Mercurial，SVN或其他工具可以很好地工作嗎？當項目樹有二進制文件時，GIT，Mercurial，SVN或其他版本控制工具可以工作嗎？
例如，如果規範是用.doc編寫的，並且它是存儲庫的一部分，那麼如果它是4MB，編輯了100次，但僅用於1或2行，並在一年中檢查了100次，那麼它是400MB。
如果它是100個不同的.doc和.xls文件，那麼它是40GB ...不是容易管理的大小。
我已經嘗試過GIT和Mercurial，並且看到它們似乎都增加了大小的數據，即使在.doc或.pdf中更改了1行時也是如此。 GIT或Mercurial或SVN中有其他方式可以完成這項工作嗎？
一般來說，版本控制系統的文本文件，更好地工作。整個合併/衝突概念實際上基於源代碼。但是，SVN在二進制文件中工作得很好。 （我們使用它來版本CAD圖紙。）
我會指出，當有多個人在一個普通的二進制文件上工作時，文件鎖定（svn：needs-lock）是非常必要的。在沒有文件鎖定的情況下，2人可以一次處理二進制文件。有人首先進行修改。猜猜沒有提交的人會發生什麼。他們所做的所有二元/不可消除的工作實際上已經失去。文件鎖定序列化在文件上工作。你確實失去了版本控制系統的「併發」訪問能力，但你仍然可以獲得提交日誌的好處，回滾到以前的版本等。
TortoieSVN客戶端足夠聰明，可以使用MS Word的內置在合併工具中區分doc/docx文件。它還具有配置選項，可讓您根據文件擴展名指定替代diff工具，這非常酷。 （這是一個恥辱，沒有人爲我們的CAD軟件包製作差異化工具）。
當前代DVCS如Git或Hg往往會吸收二進制文件。他們沒有任何形式的文件鎖定機制。
查看mercurial wiki page about Binary files。你的主要問題是，即使文件（如doc和其他文件）的微小變化也會引起文件結構的巨大變化（部分原因是因爲它被壓縮）。
因此，我不相信你會發現在版本控制系統中處理這些文件的好方法。
這是一個有效的觀點：將Word，Excel和Openoffice默認保存爲基於xml的「bloated」格式可能會更好，因爲SCM有更多的機會檢測差異。 – 2010-06-06 09:20:29
@Peter Tillemans：在提交之前，至少可以用'git'設置一個鉤子來在XML數據上運行'tidy';這可能會增加減少差異的機會。雖然可能需要安裝'cygwin'才能在窗口下方得到'整潔'。這也假定MS格式足夠一致，以便它們可以在它們被「整理」之後讀取它們。 – intuited 2010-06-06 18:53:31
存在二進制diff工具，但它們沒有多大幫助，因爲圖像的一個像素的更改或Word文檔中的一個字符的更改並不對應於文件中一個字節的更改，由於壓縮。因此對這種二進制數據的「好」處理是不可能的。
如果你想提交這樣的文件，考慮提交未壓縮的變體--RTF代替DOC，TeX代替PDF等。如果版本控制系統使用壓縮來壓縮其內部存儲庫，那麼這種方法應該工作得很好。例如，在Git，
新添加的對象是使用zlib壓縮存儲在它們的全部。
編輯：我只是想指出，即使RTF是可怕的，但並不像可怕的DOC。如果您可以切換到文檔的TXT或TeX，那最好。
Postscript是TeX的另一種選擇。正如在另一個答案中指出的那樣，Word可以將文件保存爲XML格式，這也是可以進行區分的。 – 2010-06-06 20:11:17
我一直在使用git在Mac，Linux和Windows機器之間同步我的文檔。我不得不做一次重新設計來規避Windows上的2Gb文件限制。總共大約7Gb在3個定期同步的軟件庫中。在某個時候，我甚至在互聯網上的某個託管服務器上都有遠程副本。
現在我幾乎不需要克隆這些回購，所以大尺寸不會妨礙很多。我也看到.git沒有顯着增加，它仍然在檢出的文檔，pdf，excel表格大小的40-60％左右。
更改doc ot pdf文件中的一行，在格式化效果波及時會在文件中發生很大變化。同樣，更改XLS文件中的單元格可能會改變很多其他單元格。
然而，沒有版本控制下的文件的情形相比，我很高興地住在一起比恆星壓縮比
恕我直言，你應該停止使用SCM來管理這些文件。你應該使用像Alfresco這樣的專用工具（我相信還有很多其他文檔管理工具）。
對於svn +1：對二進制文件的需求鎖定 – JeremyP 2010-06-08 08:39:16