2009-10-21 31 views
3

我試圖創建並遵循版本控制的最佳實踐,並遇到了Subversion中對原子提交的引用。因爲我從來沒有聽說過這個動作,所以我有幾個問題。Subversion中的原子提交的價值是什麼?

  • 它的用途是什麼?
  • 什麼時候應該使用它?
  • 它與正常提交有什麼不同?
  • 用戶是否可以使用TortoiseSVN?如果是這樣,怎麼樣?
+1

考慮一下自己的幸運吧,永遠不必使用CVS! – 2009-10-21 18:41:08

+0

我不知道最佳實踐是否都表明儘管提交本身總是原子的,但提交的原因可能不是「原子的」。這些準則可能是:確保構建在提交之前不會中斷。每個錯誤修復發佈一次提交。如果需要回滾,這個想法是爲了儘量減少疼痛。 – 2013-01-24 15:28:59

回答

16

原子提交沒有特別的命令。 Subversion中的每個提交都是原子的。這意味着每一次提交(任意數量的文件)將會成功或失敗。
不可能只有一部分提交的文件將其存入存儲庫,而其他文件則不存在(例如,由於在提交操作中發生的錯誤或其中一個文件發生衝突)。

這與TortoiseSVN相同,因爲它建立在「正常」的Subversion功能上。


以下是從Subversion book的摘錄:

的SVN提交操作發佈 更改任何數量的文件和目錄 作爲一個原子 事務。在您的工作副本中,您可以更改文件的內容;創建, 刪除,重命名和複製文件和 目錄;然後提交 完整的一組更改作爲原子 事務。

通過原子事務,我們的意思只是 這樣的:在存儲庫中的所有的變化發生 ,要麼都不 發生。 Subversion試圖在程序 崩潰,系統崩潰,網絡 問題以及其他用戶的操作中嘗試保留這種原子性。

+0

你是最不正確的,「這是不可能的」。 [這正是我和https svn的兩位同事發生的事情](http://stackoverflow.com/questions/42861248/svn-server-doing-partial-ie-non-atomic-commits) – Adrian 2017-03-17 20:18:09

2

這種情況下的「原子」是指原子操作。你可以在這裏找到一個很好的定義: http://en.wikipedia.org/wiki/Atomic_operation

SVN中的所有提交都是自動原子化的,所以你可以在任何地方免費得到它。

3

這個想法很簡單,對一個文件的更改通常與另一個文件的更改有關。一些舊的版本控制系統在一次提交中並沒有真正處理多個文件(就像你稱之爲「原子提交」),或者他們做得很差。

你不必爲此做任何特殊的事情。這就是Subversion的工作原理。但是對於Subversion,您可以選擇一次檢入一個文件,或者一次或兩次執行所有已修改的文件。

多個文件作爲一個提交的想法是,—一般來說—你應該能夠檢查出任何特定版本的存儲庫,它至少會編譯並希望運行。這對團隊很重要。現在在實踐中這可能不是100%的時間,但指導原則是正確的。

因此,無論您是做一個文件,所有您的更改一次或在您登記的內容之間應該是一個提交。就像修復了一個bug並需要修改8個文件一樣,將所有這8個文件都作爲一個提交進行檢查,並提供一條消息,說明您修復了哪些錯誤以及修復了哪些錯誤。如果出現問題,以後再推出會更容易。

+0

我被困在CVS在我的產品組中,所以我知道痛苦。我最希望得到的東西之一是'文件集提交'或者這裏提到的原子提交。 – 2009-10-21 18:29:09

1

如果你想知道什麼是原子提交是好的,想象你將一個分支合併到磁盤的trunk中。你在早上開始,午餐過後你就完成了,一切都在編譯,所有的單元測試都能成功運行。然後您提交在合併期間更改的200多個文件。

在SVN中,提交成功並且所有200個以上的文件一次性提交,或者提交失敗,並且根本沒有對存儲庫進行任何更改。 (關於這一點沒什麼值得說的,只是它本來就應該是這樣的。)

在沒有原子提交的CVS中,可能發生你的提交在150個文件後中斷,因爲有人偶然發現了網絡電纜,剩下的50多個文件沒有被提交,使存儲庫處於中間狀態。在嘗試插入網線時,您的團隊中的其他人會檢查另一組更改。這組變更與您已經簽入的變更不相交,因此其他人的提交成功。但是,這些更改是不兼容的。現在團隊堅持一個包含甚至不能編譯的代碼的存儲庫,更不用說通過任何測試了。更糟糕的是:你們兩個有一個團隊經理,他們會盡可能快地解決這些不兼容的變化,這樣團隊的其他成員就可以停止玩Quake並重新開始工作。令人驚訝的是,這樣的場景並不像看起來那麼不可能。我去過那裏好幾次了,收到了我糟糕的襯衫。

0

要了解真正使用的原子提交,請閱讀本關於持續集成:

http://en.wikipedia.org/wiki/Continuous_integration

使用實際上是關於確保您可以撤消的集成問題的情況下適用開發的所有的變化。這是保持存儲庫中代碼完整性的一個非常強大的功能。