呼籲見解：版本控制和二進制

Question

人類寫源代碼

版本控制是用來記錄在源代碼更改

工具過程的源代碼，並生成機器可讀的東西（EXEC ，庫，GUI代碼等）

每隔一段時間我想保存一份工具'輸出（例如保存用於ARM的beta版本的可執行文件）。我可以手動保存工具'輸出，給它一個反映修訂控制歷史中的點的名稱（例如使用標籤名稱）。這看起來很尷尬和容易出錯。

我想你洞察到兩兩件事：

1. 什麼是在修訂歷史圖表特定位置使用版本控制存儲工具生成的輸出的優點/缺點？你用什麼非RCS工具作爲替代方案？

2. 在善變，混帳

   ，什麼是包括特定版本工具生成的輸出，而不是別人

Answer 1

我相信二進制文件不應該在版本控制自己的源代碼一起存儲的最佳途徑。

缺點：在大項目

• 鼓勵不好的構建實踐。最佳實踐是完全自動化完整構建（不僅僅是源代碼編譯，還包括運行自動化測試，文檔打包，設置等等）。提交二進制文件使您能夠忽略：「只需手動爲已更改的部分進行構建」。
• 更新較慢，並承諾
• 需要每次做一個構建
• 提交其改變源代碼後更新，但不是相應的二進制文件將引起開發商之間的混亂的時間來處理二進制文件有衝突。你如何檢測出不匹配？
• svn update將更新您的二進制文件的時間戳，混淆您的構建工具，這會錯誤地認爲二進制文件比源代碼更新更新。
• 它在存儲庫中使用更多的磁盤空間。 （這可能可以忽略不計，具體取決於您的項目）。

通常，我認爲您應該避免提交任何以確定性方式從其他版本化資源自動生成的任何內容。沒有冗餘 - >沒有不一致的機會。

相反，使用持續集成服務器在每次提交時自動重建（並運行測試）。如果需要，讓構建服務器在某處（SVN外部）發佈二進制文件，就像網絡上的共享文件夾一樣。

Answer 2

我建議不要將二進制文件與DVCS混合在一起（例如git和Mercurial）。主要原因是：任何不可合併的文件都是DVCS的問題。DVCS從根本上依靠文件的高質量合併來實現DVCS的工作原理（請參閱this discussion on binary files in git）。

我同意二進制文件值得存儲。但他們應該可以存儲在與源代碼版本控制系統不同的地方。也許是一個受控寫入訪問的服務器。如果你想保留所有的歷史記錄，也許分開集中式VCS存儲庫，如Subversion。

爲了避免這樣的分離，如您所說的那樣「尷尬且容易出錯」，請儘量使其自動化。製作一個自動構建過程，確保源代碼版本/標記，完成構建，並將輸出（正確命名，版本化，標記等）放入指定商店。