如何安排我的SVN目錄？

Question

我的團隊中有3位開發人員，他們都在同一個.NET VB系統上工作。 他們通常在不同的功能上工作，但他們經常碰撞，導致他們改變相同的文件。 源文件在網絡設備上共享，當然每個人都有自己的工作副本（WC）。 問題是，設置SVN存儲庫的最佳解決方案是什麼？ ：

1）我將主要源文件導入到Trunk目錄，然後在3個不同的WC上籤出，每個WC在本地機器上分別針對特定用戶，然後處理來自單個Repos的所有衝突/合併/提交/更新。科。
2）我將主源文件導入到Trunk目錄，然後複製到一個「分支」目錄，然後處理所有的操作。一旦設置完畢，我就處理主幹和分支之間的合併。 3）我將主要源文件導入到Trunk目錄中，然後複製到3個不同的「分支」目錄中，例如：

svn copy trunk - > branches/user1; svn copy trunk - > branches/user2; svn copy trunk - > branches/user3

然後處理所有不同的合併，我想這有點複雜。
4）其他解決方案？

很多。

Answer 1

我更喜歡選項＃3我自己，因爲它允許每個開發人員保持個人歷史。分支和合並越容易，因此您可能會在短期內發現它的可行性。這個工作流程也很好地映射到feature branching，我認爲這是最佳實踐。

從長遠來看，如果你打算擴大這個團隊，SVN是不適合這個工作流程的。考慮一個DVCS，如Git或Mercurial如果你想以這種方式工作，因爲它們極大地簡化了分支和合並。

Answer 2

聽起來像你應該採用早期的分支模型。將主要來源導入到trunk，然後將其分支並讓您的團隊完成此工作。在正常的開發過程中，可能會出現一個人的變化與另一個人發生衝突的情況，但這在任何版本控制系統中都是可以預料的。積極主動，並將其作爲學習體驗。當您對分支中的工作滿意時，將其合併回trunk。

幾個要點：

• trunk爲王。除非你真的知道你在做什麼，trunk應該總是處於「黃金」狀態，這意味着不應該有任何違反構建的提交。
• 適當地命名您的分支機構。在本週選擇一些相關的開發任務，用適當的名字分支主幹，在其上工作，然後在本週結束時重新合併。然後，您可以刪除分支並使用新名稱從主幹創建一個新分支。隨着時間的推移，您可以爲中繼發佈標籤（v1.0，v1.1，...等）。
• 使用有意義的提交消息進行小提交。這將幫助你在3,6,12個月的時間內完成任務。

更多信息here和here。

Answer 3

首先，你說「源文件在網絡設備上共享」。你是什​​麼意思？對於某些網站，他們有共享的網絡驅動器，並使用file://進行結賬和簽入。不要這樣做，如果你這樣做。改爲使用svnserve或Apache HTTPD。 svnserve在Windows上很容易設置，並且如何將svnserve設置爲Windows服務，因此它會自動啓動並自動重新啓動。主要問題是端口3690是否被阻塞或不在您的網絡上。還有幾個Windows軟件包可以安裝已經集成的Apache httpd和Subversion。有些是完全開源的解決方案，但大多數都是免費的。

偶爾的文件衝突不應該是一個問題。 Subversion能夠以非常理智的方式處理衝突。假設開發者A簽出了一份工作副本，開發者B也是如此。開發者A和B都改變foo.vbs。開發人員B首先提交其副本。當開發者一個嘗試提交他們的修改，Subversion不會允許開發人員乙犯，直到開發商乙更新他們的工作副本，包括開發商一個的變化。一旦開發人員A執行此操作並測試其更改，他們可以提交組合的一組更改。這是你的第一個場景。

使用場景＃3，具有在一個單獨的分支中的每個開發人員的工作真的做同樣的事情爲場景＃1：兩種開發一個和乙創建從他們各自的分支幹線和結帳的一個分支。他們可以在不合並的情況下將自己的工作交給自己的分支機構，但遲早他們必須將代碼合併回主幹。然後，他們會遇到同樣的問題，第一個開發人員可以輕鬆地進行合併，但第二個開發人員必須處理任何合併衝突。

唯一的區別是你必須處理合並衝突。場景＃3允許開發者忽略合併衝突，直到遊戲結束後才能處理合並更加困難。情景＃1迫使開發人員在問題仍然很小時立即處理問題。我有幾十個開發人員都在同一個分支上工作，沒有任何問題。