文章目錄

• 自己的猜想
• • 文件名比對
  • 文本行比對
• 事實是什么
• 提交計劃
• 提交數據
• 更新客戶端版本庫數據時，同名文件中文本行的數據比對規則

自己的猜想

假設當前用戶提交的文件稱為 NF，SVN 最新版的文件稱為 HF。

文件名比對

首先比對文件名，如果文件名不同，則比對文件屬性的元數據，文件 ID 是相同的，說明屬于同一個文件，則比對文件名稱的版本號，發現 NF 文件名的版本號為 Undefined，說明 NF 文件修改了文件名，于是從客戶端的緩存庫中獲取 NF 文件舊名稱的版本號與 HF 文件的名稱的版本號比對，發現相同或者 NF 文件舊名稱的版本號更大，則保留 NF 文件的文件名；若 NF 文件舊名稱的版本號比 HF 名稱的版本號小，說明什么問題？說明 HF 文件也曾修改了文件名并且提交了更新；其二當前用戶沒有更新最新版的數據，而是在舊版本基礎上進行更新和提交。所以現在沖突就產生了，保留誰的文件名，兩位提交者相互協商后手動解決沖突了。

文件名不同，比對文件屬性的元數據，發現文件 ID 也不同，說明不屬于同一個文件，而是新增的文件，此時 SVN 會在客戶端的緩存庫中追溯版本數據（客戶端會緩存文件的各種歷史版本），試圖尋找到 HF 文件的相關數據，結果找到了，發現原來的文件被刪除了，于是會比對被刪除文件的版本和 HF 文件的版本，如果被刪除文件的版本大于等于 HF 的版本號，則遵從提交的數據包，不再保留 HF 文件；如果被刪除文件的版本號小于 HF 文件的版本號，說明兩個問題，其一 HF 文件是后來有人更新后提交的；其二當前用戶沒有更新最新版的數據，而是在舊版本基礎上進行更新和提交。因此這樣的刪除行為 SVN 服務器是不會直接通過的，所以沖突產生了。被刪除的文件是否保留，兩位提交者相互協商后手動解決沖突了。

如果 SVN 在追溯版本數據的時候沒有找到 HF 文件相關的數據，則說明當前用戶提交的是新增數據，于是保留 NF 和 HF 兩份文件到 HEAD 片段中，而原來的 HF 文件會被歸檔到舊版本片段中。此時其他用戶從 SVN 檢出或導出或更新就會得到兩份文件了。

如果 NF 和 HF 的文件名相同但是文件 ID 不同，也就是說實際是兩個不同的文件，但是取名相同（例如，當前用戶下載了 HF 文件，后來刪除了，又重新創建了一份同名的文件），文件系統是不允許同個目錄下存在兩份同名的文件的，所以此時 SVN 也是在客戶端的緩存庫中追溯版本數據，如果發現當前用戶刪除了與 HF 同 ID 的文件，而且版本相同，則 SVN 會遵從當前用戶的提交只保留當前用戶的提交的文件；如果當前用戶刪除的與 HF 同 ID 的文件版本更小，則 SVN 不會直接通過，所以沖突產生了。保留哪個文件，兩位提交者相互協商后手動解決沖突。

文本行比對

如果文件名和 ID 都相同的情況下，則逐行比對文件內容。

NF 的第 1 行與 HF 的第 1 行比對，先比對內容，內容相同則 NF 的第 1 行內容保留下來，內容不同則比對行的版本號，如果 NF 的第 1 行的版本號是 Undefined，則追溯該行的舊版本數據，如果發現 NF 文件的第 1 行的舊版本號等于 HF 文件的第 1 行的版本號，則保留 NF 第 1 行的數據，如果 NF 文件的第1行的舊版本號小于 HF 文件的第 1 行的版本號，則產生沖突，需要手動解決。所以基于這樣的邏輯，多人同時修改同一位置的數據最先提交的數據順利通過，但是后面提交的數據都會產生沖突，因為從客戶端緩存庫中提取到的版本數據肯定被 SVN 服務器 HEAD 片段的數據的版本小。這里說的 HEAD 片段其實就是所謂的“集中式版本庫”，SVN 用戶都是從這個版本庫中下載最新版本的數據資源。

NF 的第 1 行與 H F的第 1 行比對，內容不同，則比對版本號，如果可以直接取到 NF 文件第 1 行的版本號，則說明 NF 文件的第 1 行沒有修改過，如果版本號相同，則直接保留 NF 的第1行文本內容，如果 NF 文件的第 1 行的版本號低于 HF 文件的第 1 行的版本號，這說明當前用戶在提交的時候沒有更新最新版的數據直接提交了，但是沒有關系，SVN 知道 NF 文件中的第 1 行文本是舊數據，所以會保留 HF 文件的第 1 行數據。

按上述的邏輯比對后面的所有文本行…

事實是什么

在提交的時候，SVN 并不是按以上的邏輯和規則來比對數據，中央版本庫中原來的數據會移入歷史版本池中，然后備份一份到 head 分區中（即主分支 /trunk），接著簡單判斷同名文件內容是否一致，一致則保留 head 的數據，否則被新提交的文件替換掉。

在客戶端版本庫的緩存數據中，有保存客戶端版本庫的文件的實際路徑與 SVN 服務端版本庫中的對應路徑的映射關系。只要有修改客戶端版本庫中的數據，都會把被修改文件的客戶端路徑和相對應的 SVN 服務端版本庫的路徑寫入到提交計劃中。

所謂 versioned 就是每個客戶端版本庫的文件都在這個路徑映射表中，如果你改了客戶端版本庫中的文件名或者刪除了，SVN 客戶端就無法找到對應的映射關系，就會提示文件丟失、無法識別等。

提交計劃

客戶端版本庫的文件只要修改了內容，或者通過命令 svn add 添加的文件，相關文件的路徑都會寫入提交計劃中（schedule）

提交數據

只要客戶端版本庫的版本號和服務端版本庫的版本號不同，就無法正常提交，提示“過期”

如果提交數據成功，是將工作副本的數據完全覆蓋服務端的數據，沒有進入文件內容進行文本行的數據比對

更新客戶端版本庫數據時，同名文件中文本行的數據比對規則

內容對比客戶端標記狀態服務端標記狀態內容處理方案

不相同	刪除	修改過	產生沖突
相同	刪除	未修改過	遵從客戶端的
相同	未修改過	未修改過	遵從客戶端的
相同	修改過	修改過	遵從客戶端的
不相同	修改過	未修改過	遵從客戶端的
不相同	修改過	修改過	產生沖突
不相同	未修改過	版本不同	遵從服務端的
相同	未修改過	刪除	遵從服務端的
相同	修改過	刪除	產生沖突
不相同	修改過	刪除	產生沖突

注：服務端文本是否修改過，是針對客戶端文本行的版本而言。

總結

以上是生活随笔為你收集整理的SVN 版本控制的数据合并规则的全部內容，希望文章能夠幫你解決所遇到的問題。

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