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

文件共享的問題

考慮這個(gè)情景，我們有兩個(gè)共同工作者，Harry 和 Sally，他們想同時(shí)編輯版本庫里的同一個(gè)文件，如果首先 Harry 保存它的修改，過了一會(huì)，Sally 可能湊巧用自己的版本覆蓋了這些文件，Harry 的更改不會(huì)永遠(yuǎn)消失(因?yàn)橄到y(tǒng)記錄了每次修改)，Harry 所有的修改不會(huì)出現(xiàn)在 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. 鎖定-修改-解鎖 方案

鎖定-修改-解鎖模型有一點(diǎn)問題就是限制太多，經(jīng)常會(huì)成為用戶的障礙:

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

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

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

復(fù)制-修改-合并 方案

Subversion，CVS 和一些版本控制系統(tǒng)使用復(fù)制-修改-合并模型，在這種模型里，每一個(gè)客戶讀取項(xiàng)目版本庫建立一個(gè)私有工作副本—版本庫中文件和目錄的本地映射。用戶并行工作，修改各自的工作副本，最終，各個(gè)私有的復(fù)制合并在一起，成為最終的版本，這種系統(tǒng)通常可以輔助合并操作，但是最終要靠人工去確定正誤。

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. 復(fù)制-修改-合并 方案

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

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

復(fù)制-修改-合并模型感覺是有一點(diǎn)混亂，但在實(shí)踐中，通常運(yùn)行的很平穩(wěn)，用戶可以并行的工作，不必等待別人，當(dāng)工作在同一個(gè)文件上時(shí)，也很少會(huì)有重疊發(fā)生，沖突并不頻繁，處理沖突的時(shí)間遠(yuǎn)比等待解鎖花費(fèi)的時(shí)間少。

最后，一切都要?dú)w結(jié)到一條重要的因素: 用戶交流。當(dāng)用戶交流貧乏，語法和語義的沖突就會(huì)增加，沒有系統(tǒng)可以強(qiáng)制用戶完美的交流，沒有系統(tǒng)可以檢測(cè)語義上的沖突，所以沒有任何證據(jù)能夠承諾鎖定系統(tǒng)可以防止沖突，實(shí)踐中，鎖定除了約束了生產(chǎn)力，并沒有做什么事。

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

Subversion 怎么做？

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

轉(zhuǎn)載于:https://www.cnblogs.com/mingyongcheng/archive/2011/03/22/1991550.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。