基於我讀過關於版本控制幾個帖子，似乎讓人覺得在版本控制系統悲觀鎖是一件壞事。爲什麼？我知道它阻止了一個開發人員提交了一個更改，而另一個開發人員檢出了該文件，但那又如何？如果你的代碼文件非常大，你不斷地對他們工作在同一時間不止一個人，我認爲你應該重新組織你的代碼。將其分解成更小的功能單元。爲什麼要避免在版本控制系統悲觀鎖定？
即使使用良好的版本控制系統提供的工具來簡化併發代碼更改，也是一個單調乏味且容易出錯的過程。如果可能的話，我認爲應該避免。那麼，爲什麼悲觀鎖定不受歡迎？
這取決於你的項目和團隊。悲觀鎖定很好，因爲它很容易理解 - 一次只有一個開發者，並且不需要合併！
然而，壞事恰恰就是 - 一次一個開發者。我現在有一個同事在現場的情況，在他離開之前，他檢查了一切，如果他必須修復任何錯誤，他可以返回並檢查他所有的變化......對他來說很好，對我和基地其他開發團隊來說都很糟糕。
如果你能避開你團隊中的悲觀鎖定，那麼它很好用，真的，人們討厭它的最大原因是它的Visual SourceSafe的默認實踐。如果你對合並很多變更沒有信心，那麼你有另一個使用它的理由 - 如果你曾經使用過樂觀鎖定SCM，並且合併了一個合併，你就會知道它有多難復原。
如果你可以處理合並，樂觀鎖定是優越的，我會推薦它，但是如果你不想使用它，你不必交出你的極客卡。
軟件開發人員總是樂觀 - 只要看看他們的估計skils！
在實踐中，我們發現衝突很少見，無需擔心鎖定的好處超過偶爾的衝突解決步驟。
我完全同意，斯科特。 – itsmatt 2008-09-26 16:18:50
我同意，但爲什麼參考SourceSafe？我們在併發結賬模式中使用了很多年 - 沒有問題。 （我從來沒有真正理解VSS的所有仇恨，我想我們很幸運）。 – 2008-09-26 17:19:04
悲觀鎖定是（個人經驗）的合作方式。有時很容易被良好的團隊溝通取代。只是說「嗨，我會在這幾個文件上工作一段時間」。
我已經在2至6人的團隊中工作，沒有鎖定，我們從來沒有遇到任何問題，超出了一些常見和必要的合併。
我還曾在鎖定Visual SourceSafe託管項目中工作過一次。這是恕我直言適得其反。
如果開發人員不能處理合並和固定的衝突，他應該被再教育。
即使是小文件也會發生衝突，例如使用JSP，一個人（Web開發人員）可能會更改佈局代碼，而其他人可能會更改JSP所使用的模型的API。
我已經看到它一次又一次地發生。開發商這樣做，因爲這個過程很煩人：
悲觀鎖定感覺像是業餘時間，對不起。
如果你的代碼文件非常大，你不斷地對他們工作的同時
如果是這樣它的時候了「人類」，負責和案件不止一個人協調任何更改。在理想的情況下，如果你的項目管理是好的，你很少會想到你試圖更換鎖定文件的時候，因爲有人會協調好事情，所以實際上不會發生。
換句話說，如果你在組件X中有一個錯誤修復，你會知道'Bob'正在對組件X/Y/Z進行一系列修改，你會知道在嘗試提交之前要與Bob交談你的改變。
正如我說，這是理想的;）
悲觀鎖是，如果嚴重的衝突將是可能是個好主意。對於大多數編程，你不會看到任何嚴重的衝突，所以悲觀鎖定是毫無意義的。例外情況是，如果你是：
否則......
關於與鮑勃和約翰的情況下，像SVN協同系統沒有避免這種情況不是鎖定系統做任何更多。我可以'更新'FooBar.java，它滿足了我擁有最新版本的svn，然後在本地刪除該文件，並使用我自己的個人副本覆蓋它，而不考慮基準版本，並檢查該文件是否可以快速銷燬另一個人的變化。 沒有系統，鎖定與否，阻止了這一點，所以我沒有看到即使把它帶入辯論的重點。
真正的問題是決定您的餘額是多少
之間的鎖定文件
的概念，要麼鎖定或非鎖定系統是「上級引起人們 不便合併錯誤 與可能性「是無稽之談。
我使用VSS，在其默認的完全鎖定模式，具有6個開發者，和它的工作就像 一個夢想。有時候，有人會忘記釋放一個鎖，我們不得不狩獵他們或手動打破鎖，並在他們返回時手動合併，但這是非常小的。我已經看到svn不止一次地搞砸了自動合併，所以我不太相信它。當兩個人以無法自動合併在一起的方式更改同一文件時，它並不總是會標記「衝突」。相反，我發現人們對VSS的鎖感到不耐煩，編輯他們自己的副本，，並在其他人的代碼頂部檢查他們，我見過 svn輕易地抓到我，當我可能不小心嘗試檢查自從我上次檢查出來以來已被其他人更改過的內容。
我的觀點是，這不是一個明智的辯論有。無論是系統的成功歸結 當他們出現，而不是是否一個系統 或其他比較好，你如何管理衝突點。
「軟件開發人員總是樂觀主義者 - 只要看看他們的估算技巧！」 - 愛它！！ – tjjjohnson 2009-05-21 22:25:20