我是來自Visual Source Safe（VSS）背景的Subversion（SVN）的新手。在VSS中，編輯文件的人員將檢出文件，並鎖定其他用戶通過Visual Studio進行編輯。我知道SVN是一個併發模型，允許多個人在同一個文件上工作，然後將這些更改合併在一起。我的問題是這樣的：如何避免Subversion中的複雜合併？
什麼是避免用戶編輯同一文件（寫成噸的代碼），要麼面臨自己的改變或一個複雜的合併書寫更糟糕的一噸的代碼，最好的方法只發現該文件被另一個用戶鎖定？
有沒有辦法來通知檢索文件時，它是當前正由另一用戶編輯或正在被其他用戶鎖定用戶？
其他信息：
使用VisualSVN服務器爲SVN服務器。
使用TortoiseSVN和AnkhSVN客戶端。
我也是以前的Visual Source Safe用戶。在我意識到這不是一個技術問題，而是一個人的問題之前，合併曾經讓我瘋狂。在使用VSS時，大多數開發人員在必須簽入代碼之前儘可能完成儘可能多的工作。這種行爲是造成複雜合併的原因。
以下是減輕這種幾件事情：
這些事情非常有幫助，尤其是當我工作的團隊不斷變得越來越大時。從VSS複製鎖定行爲是一個非常糟糕的主意，並且會導致更多問題。只需擁抱新的工作流程。
如果你仍然想使用的工具，那麼我建議你看看SVNMonitor。
感謝您推薦SVNMonitor。 – Achilles 2009-11-12 16:26:29
你錯過了一件重要的事情，使分支一起工作的喜悅。經常更新...樹幹變化人們已經登記到您的分支機構。和你在第一點中所說的一樣。對你的分支做同樣的事情，不應該有任何不同的對待。如果您經常更新您的分支，並且人們每天都會檢查一下主幹，那麼最終不會有任何合併地獄，因爲您的分支中的代碼幾乎是最新的或接近最新的幹什麼，因爲你宗教上更新你的分支一直！每日小小的痛苦讓生活變得輕鬆 – PositiveGuy 2012-02-10 05:16:07
我想建議採取不同的方法來使用顛覆。
採用這種方法，合併通常是罕見且自動發生。在衝突的情況下，這些往往較小。
首先，它可能是明智的，避免寫「成噸的代碼」沒有檢查的文件，如果可能的話。如果你有一個很好的單元測試套件（如果沒有，爲什麼不呢？），那麼只要你在綠色欄上籤入，頻繁的提交是最好的。
然後，如果確實需要花費很長時間的更改，則定期執行svn update以儘可能保持與主幹同步。 Subversion在合併時相當可觀（與VSS相比），並能很好地處理大部分內容。
任何它無法處理的東西，它將進入衝突狀態，讓你解決與你選擇的合併工具的衝突（我建議WinMerge這是它的王牌）。
SVN是一個並行模型，允許多個人對同一文件進行操作以後的修改合併到一起。
我認爲這更多的是在同一個項目是由一堆獨立的文件或多或少的工作。處理同一個文件併合並結果肯定是可能，並且確實會偶爾發生，但絕對不是默認/所需的操作模式。所以：
我在之前的地方從基於鎖的系統到SVN的過程中遇到了一些問題。
在SVN中嘗試並複製鎖定編輯 - 解鎖行爲並不是一個好主意，因爲它的設計方式不需要這樣工作。 SVN使用的合併算法相當不錯，而且我只遇到了一些需要在合併過程中手動干預的情況。令人驚訝的是，在同一個文件上工作的兩個人實際上會碰到同一條線，而後者往往是唯一需要手動干預的時間。
SVN確實是設計用於您從幹線或當前分支經常更新的環境中。如果你必須做更長期的工作或者改變文件中大量代碼的工作，那麼最好使用分支來完成工作併合並它。是的，你必須通過一些合併時不時的疼痛，但它比不用這種方式設計的系統的疼痛要少得多。
如果您嘗試使用SVN而不是「本機SVN」，而是使用不同名稱的VSS，這將是痛苦的，它不值得冒險。爲了適應新的範例，與舊的「只有一個用戶在任何給定時間編輯給定文件」例程相比，您會驚訝地發現以這種方式工作的更好。
簡短的回答：
稍長的答案：
如果不止一個開發者在同一個文件「成噸的變化」，事情是腥要麼與方式的開發工作，或與方式功能分佈在不同的文件中。我一直在與CVS和SVN以不同規模的團隊合作，並且在合併成爲真正的問題時，極少有情況。 （這通常是像串，日誌，錯誤處理等需要改變幾乎所有的代碼基本服務的變化。這種情況下，需要一些人的互動，並計劃順利進行。）
我同意其他人一樣，在儘可能在檢查儘早並經常（但並不總是可能）。如果你正在做一些複雜的，新的它可以在一個分支來實現 - 應用同樣的規則，提交儘早並經常與地方保持你的分支爲最新從起始碼爲實用。
在我們大部分人的經歷往往不會在同一個文件或至少文件的同一部分工作在同一時間（VSS你不能所以你的工作模式可能已經支持你在這）。
還有一個關鍵問題 - 確保每個人都使用相同的規則來使用製表符和間距，進行佈局和格式化，無論如何，這是一個很好的做法，但是一致性越高，您越不可能找到「不存在的代碼文件之間的差異「。
另外，我建議你看看持續集成，即有一個構建服務器，這提供了相當大的好處，你的承諾代碼將建立在「乾淨」的環境中，如果你有適當的測試，即使在複雜的合併過程之後，它也會給你更大的信心，即它仍然有效。
我們使用TeamCity我們發現這是極好的 - 但也有其他人。
雖然SVN有一個鎖命令，但使用SVN的最常見方式是使用樂觀的鎖定方法。
這意味着你和我可以編輯同一文件，並不太擔心它（大多數時候我們不會因爲我們想對我們的項目不同部分的工作時間）。如果我第一次提交對文件的更改，那麼提交嘗試將失敗。那時SVN會通知你。
然後，您將必須運行「更新」命令，將（最有可能）會自動與您當地的更改，然後下次提交的嘗試將通過合併我提交的修改。
爲了避免陷入麻煩，這種樂觀的辦法：爲別人的建議，承諾往往在一次不要犯太多了！
你可能想使用舊的VSS風格鎖定模型中的唯一時間是要版本的二進制文件（MS-Word文檔等），但SVN無法自動合併來自多個來源的變化。
謝謝大家的所有建議，並設置我直。 – Achilles 2009-11-12 16:20:14
一年來不及，但我真的不得不推薦閱讀SVN手冊。它是以一種輕鬆，實用的方式編寫的，並且像一個廣泛的SO答案一樣閱讀。 – 2010-09-16 11:20:35