所有的版本控制系統都需要解決這樣一個基礎問題: 怎樣讓系統允許用戶共享信息，而不會讓他們因意外而互相干擾？版本庫里意外覆蓋別人的更改非常的容易。

文件共享的問題

考慮這個情景，我們有兩個共同工作者，Harry 和 Sally，他們想同時編輯版本庫里的同一個文件，如果首先 Harry 保存它的修改，過了一會，Sally 可能湊巧用自己的版本覆蓋了這些文件，Harry 的更改不會永遠消失(因為系統記錄了每次修改)，Harry 所有的修改不會出現在 Sally 的文件中，所以 Harry 的工作還是丟失了—至少是從最新的版本中丟失了—而且是意外的，這就是我們要明確避免的情況！

圖 2.2. 需要避免的問題

鎖定-修改-解鎖 方案

Many version control systems use a lock-modify-unlock model to address this problem, which is a very simple solution. In such a system, the repository allows only one person to change a file at a time. First Harry must lock the file before he can begin making changes to it. Locking a file is a lot like borrowing a book from the library; if Harry has locked a file, then Sally cannot make any changes to it. If she tries to lock the file, the repository will deny the request. All she can do is read the file, and wait for Harry to finish his changes and release his lock. After Harry unlocks the file, his turn is over, and now Sally can take her turn by locking and editing.

圖 2.3. 鎖定-修改-解鎖 方案

鎖定-修改-解鎖模型有一點問題就是限制太多，經常會成為用戶的障礙:

• 鎖定可能導致管理問題。有時候 Harry 會鎖住文件然后忘了此事，這就是說 Sally 一直等待解鎖來編輯這些文件，她在這里僵住了。然后 Harry 去旅行了，現在 Sally 只好去找管理員放開鎖，這種情況會導致不必要的耽擱和時間浪費。

• 鎖定可能導致不必要的線性化開發。如果 Harry 編輯一個文件的開始，Sally 想編輯同一個文件的結尾，這種修改不會沖突，設想修改可以正確的合并到一起，他們可以輕松的并行工作而沒有太多的壞處，沒有必要讓他們輪流工作。

• 鎖定可能導致錯誤的安全狀態。假設 Harry 鎖定和編輯一個文件 A，同時 Sally 鎖定并編輯文件 B，如果 A 和 B 互相依賴，這種變化是必須同時作的，這樣 A 和 B 不能正確的工作了，鎖定機制對防止此類問題將無能為力—從而產生了一種處于安全狀態的假相。很容易想象 Harry 和 Sally 都以為自己鎖住了文件，而且從一個安全，孤立的情況開始工作，因而沒有盡早發現他們不匹配的修改。

復制-修改-合并 方案

Subversion，CVS 和一些版本控制系統使用復制-修改-合并模型，在這種模型里，每一個客戶讀取項目版本庫建立一個私有工作副本—版本庫中文件和目錄的本地映射。用戶并行工作，修改各自的工作副本，最終，各個私有的復制合并在一起，成為最終的版本，這種系統通?？梢暂o助合并操作，但是最終要靠人工去確定正誤。

Here's an example. Say that Harry and Sally each create working copies of the same project, copied from the repository. They work concurrently, and make changes to the same file A within their copies. Sally saves her changes to the repository first. When Harry attempts to save his changes later, the repository informs him that his file A is out-of-date. In other words, that file A in the repository has somehow changed since he last copied it. So Harry asks his client to merge any new changes from the repository into his working copy of file A. Chances are that Sally's changes don't overlap with his own; so once he has both sets of changes integrated, he saves his working copy back to the repository.

圖 2.4. 復制-修改-合并 方案

圖 2.5. 復制-修改-合并 方案(續)

但是如果 Sally 和 Harry 的修改重疊了該怎么辦？這種情況叫做沖突，這通常不是個大問題，當 Harry 告訴他的客戶端去合并版本庫的最新修改到自己的工作副本時，他的文件 A 就會處于沖突狀態: 他可以看到一對沖突的修改集，并手工的選擇保留一組修改。需要注意的是軟件不能自動的解決沖突，只有人可以理解并作出智能的選擇，一旦 Harry 手工的解決了沖突(也許需要與 Sally 討論)，他就可以安全的把合并的文件保存到版本庫。

復制-修改-合并模型感覺是有一點混亂，但在實踐中，通常運行的很平穩，用戶可以并行的工作，不必等待別人，當工作在同一個文件上時，也很少會有重疊發生，沖突并不頻繁，處理沖突的時間遠比等待解鎖花費的時間少。

最后，一切都要歸結到一條重要的因素: 用戶交流。當用戶交流貧乏，語法和語義的沖突就會增加，沒有系統可以強制用戶完美的交流，沒有系統可以檢測語義上的沖突，所以沒有任何證據能夠承諾鎖定系統可以防止沖突，實踐中，鎖定除了約束了生產力，并沒有做什么事。

有一種情況下鎖定-修改-解鎖模型會更好，也就是你有不可合并的文件，例如你的版本庫包含了圖片，兩個人同時編輯這個文件，沒有辦法將這兩個修改合并，Harry 或 Sally 會丟失他們的修改。

Subversion 怎么做？

Subversion 缺省使用復制-修改-合并模型，大多數情況下可以滿足你的需求。然而，Subversion 1.2 后還是支持鎖定，如果你有不可合并的文件，或者你只是想實行強制管理策略，Subversion 仍然會提供你需要的特性。

轉載于:https://www.cnblogs.com/mingyongcheng/archive/2011/03/22/1991550.html

總結

以上是生活随笔為你收集整理的版本模型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。