具有不同svn存儲庫的不同項目中的代碼管理

Question

首先，我想告訴你我有什么樣的系統，我想要建立。

1- A Solution (has)
   a- Shared Class Library project (which is for lots of different solutions)
   b- Another Class Library project (which is only for this solution)
   c- Web Application project (which main part of this solution)
   d- Shared Web Service project (which also serves for different solutions)

2- B Solution (has)
   a- Shared Class Library project (which is for lots of different solutions)
   c- Windows Form Application project (which is main part of this solution)
   d- Web Service project (which also serves for different solutions)

和其他類似的項目......

我使用xp-dev.com作為我們的svn存儲庫服務器。 我為這些項目打開了不同的項目（ 共享類庫，Web服務項目，Windows窗體應用程序項目，Web應用程序項目，另一個類庫項目 ）。

我當然希望對所有這些項目進行版本控制。

我的第一個問題是，我是否應該將每個項目（一個解決方案）放到一個svn存儲庫中以便稍后獲取其修訂版號？

或者我應該將它們中的每一個放到不同的svn存儲庫中並保留（寫下）用於發布/部署每個解決方案的正確版本號？

如果我為每個項目使用一個svn（共享類庫，Web應用程序，共享Web服務......），如何在真實解決方案中將VS.2010上的正確svn地址和版本關聯起來？

那么，您如何管理您的存儲庫和項目？

Answer 1

我相信對此的正確解決方案是標記。 我不相信將您的解決方案分隔到不同的存儲庫是個好主意。 建議在同一個存儲庫中保留所有甚至略有相關的項目，並使用標准的存儲庫布局，即：

/枝
/標簽
/樹干

使用上面描述的所有工作解決方案文件夾在/ trunk中。 Trunk可以包含您認為可管理的項目/解決方案，甚至可以按項目類型進一步組織。 我的一個主干文件夾是/ trunk / website，我將所有的網站解決方案保存在那里。

當您准備好發布版本時，您可以使用“分支/標記”覆蓋/標記/“標記”您的主干或部分主干，這樣您就有機會記錄您的在標記的副本中發布說明。

有關SVN中的分支和標記的更多信息（假設Tortoise），請參閱TortiseSVN文檔中的分支/標記 。

有關這些術語的更多信息， 請參閱 StackOverflow中的此問題 。

我希望這是有幫助的。 我不知道您的SVN主機可能面臨的限制。 這些建議是基於我在托管我自己的VisualSVN Server存儲庫方面的經驗。

我從SourceSafe來到SVN，花了一些時間才看到這個標准的價值，並開始使用這些實踐。 它們對我來說非常寶貴。

Answer 2

您可以采用的另一種方法是使用Subversion externals屬性來管理您的代碼，可以在單獨的存儲庫中，也可以在單個存儲庫中。 優點是，當您需要在解決方案中使用新版本的共享代碼時，您可以簡單地更新相關URL。

注意 ：我不記得關於Visual Studio解決方案和項目組織的傑克; 自從我完成任何Windows開發以來至少已有5年了。 話雖這么說，無論文件/目錄布局是什么，這個討論都適用。 我打算做一個，請根據你的實際情況進行調整。

讓我們假設您有一個大型存儲庫，其中包含所有相關項目。 如果你認為這不一定是可擴展的，我建議看看Apache項目的SVN設置 ; 他們將所有項目都放在一個存儲庫中。 從ASF獲取頁面，讓我們按如下方式開始存儲庫結構：

/SolutionA/trunk
/SolutionA/tags
/SolutionA/branches

/SolutionB/trunk
/SolutionB/tags
/SolutionB/branches

/SharedClassLib/trunk
/SharedClassLib/tags
/SharedClassLib/branches

/SharedWebService/trunk
/SharedWebService/tags
/SharedWebService/branches

到目前為止，這只是一個標准的SVN布局; 每個或多或少的獨立實體都有自己的存儲庫區域。 現在，讓我們假設您已經開始使用SharedClassLib，並且您的版本為2.0.0，而在SharedWebService上您使用的是版本1.2.5。 目錄布局如下所示：

/SharedClassLib/tags/1.0.0
/SharedClassLib/tags/1.5.0
/SharedClassLib/tags/2.0.0

/SharedWebService/tags/1.0.0
/SharedWebService/tags/1.2.0
/SharedWebService/tags/1.2.5

其他標簽只是為了說明您的開發一直在不斷發展並且您已經有多個版本。

現在，回到SolutionA，您有一個LocalClassLibrary項目和一個LocalWebApp項目。 這些項目嚴格地是此解決方案的一部分，不在此解決方案之外共享。 在目錄布局中進行攻擊，您的主干可能看起來像：

/SolutionA/trunk/SolutionA/<some_solution_level_files>
/SolutionA/trunk/SolutionA/LocalClassLibrary/<some_project_level_files>
/SolutionA/trunk/SolutionA/LocalWebApp/<some_project_level_files>

所以，我們的問題是，我們如何將SharedClassLib和SharedWebService納入我們的SolutionA？ 通過使用Subversion外部。 首先閱讀外部網頁，然后回到這里。

為了讓您的生活更輕松，我建議您在解決方案目錄中創建一個svn.externals文件，以便在從命令行執行此操作時設置svn：externals屬性。 如果您正在使用其他工具，請記住，在這種情況下，您將需要添加多行。 該文件將如下所示：

SharedClassLib         http://your.svn.server/SharedClassLib/tags/2.0.0
SharedWebService       http://your.svn.server/SharedWebService/tags/1.2.5

編輯1 ：此時，您可以看到您引用的URL是完全限定的。 這意味着它們可以是單獨的存儲庫，您不必使用我在此描述的布局。 此外，如果您處於開發的中間階段，並且需要最新的，前沿的共享代碼開發版本，請使用http://your.svn.server/SharedClassLib/trunk類的URL。 但是，在某些時候，在標記和發布解決方案之前，您將需要確定外部代碼的黑貂版本。

編輯2 ：請注意，這是1.5之前的svn語法。 它在1.5中有所改變

做一個svn propset svn:externals -F svn.externals . 在您的解決方案目錄中，然后svn commit && svn update 。 此時，svn將使用這些URL的內容填充您的工作副本。 您的工作副本看起來像：

./SolutionA/svn.externals
./SolutionA/<some_solution_level_files>
./SolutionA/LocalClassLibrary/<some_project_level_files>
./SolutionA/LocalWebApp/<some_project_level_files>
./SolutionA/SharedClassLibrary/<some_project_level_files>
./SolutionA/SharedWebApp/<some_project_level_files>

當您需要引入共享項目的新版本時，請相應地更新svn：externals屬性。 請注意，這種方法有一些注意事項，並在SVN外部文檔中有詳細說明。 主要是，不打算能夠在./SolutionA/SharedClassLibrary中進行更改，並期望在SolutionA中提交時可以神奇地獲取更改。

現在您已准備好向全世界發布SolutionA。 只需在trunk目錄中創建trunk的相應標記（svn copy）：

/SolutionA/tags/1.0.0

現在，您的SolutionA將在正確的標記/版本上擁有自己的代碼，並且您正在為該版本使用正確版本的共享項目。

顯然，同樣的討論適用於SolutionB。

我有一段時間沒有和SVN合作過，所以如果我上面的任何一點有點不對，我很抱歉。

Answer 3

我的建議是將相同的生命周期放入相同的存儲庫項目中 。

我們來看看你的場景吧。 我們有：

1. 共享類庫項目（適用於許多不同的解決方案）
2. 另一個類庫項目（僅適用於此解決方案）
3. Web應用程序項目（該解決方案的主要部分）
4. 共享Web服務項目（也適用於不同的解決方案）

這將為2和3創建一個存儲庫，它們是同一解決方案的不同項目（因此具有相同的生命周期）：

/solution-A/trunk/ClassLib
/solution-A/trunk/WebApp
/solution-A/tags/1.0.0/ClassLib
/solution-A/tags/1.0.0/WebApp

假設他們有不同的生命周期，一個存儲庫為1，另一個為4。

/library-A/trunk/ShClassLib
/library-A/tags/1.0.0/ShClassLib
/library-B/trunk/ShWebService
/library-B/tags/1.0.0/ShWebService

現在，根據開發人員正在使用的主題，他可以檢查主干，標簽（只讀）或分支。 例如，使用已發布的庫處理解決方案的開發人員將檢查解決方案的主干和庫的正確標簽。 需要下一版本庫的同一個將檢查庫的主干（或分支）等。

當然，擁有一個能夠為庫和夜間構建提供二進制版本的構建/發布系統可能會更好。

Answer 4

關於Visual Studio支持真的沒什么可說的，因為使用Subversion和Tortoise在Visual Studio中不起作用。 在處理項目和解決方案時，您可能需要仔細考慮項目和解決方案設置是否會影響其他用戶。 例如，如果您的本地路徑與存儲庫中的項目不同，則可能必須簽出項目和解決方案文件並將其永久簽出。

對於Web應用程序，如果文件中存在特定於計算機的設置，則可能需要仔細考慮web.config文件。 例如，如果您正在運行IIS 7並且下載了使用IIS 6創建的項目，則項目文件可能會更改為指向不同位置的系統模塊和處理程序引用。 或者，您可能有一個連接字符串指向與原始web.config文件不同的服務器。 這里的解決方案也是最初下載文件，然后在本地檢出文件並記住不要更新它。

我真誠的建議是把項目放到同一個庫中; 它很容易找到和備份。 但是在創建新分支並在存儲庫中添加新文件時要記住的關鍵是：

首先在存儲庫中創建文件夾

只將文件夾簽出到本地文件夾

在資源管理器中添加Tortoise文件

提交更改

邊注：

如果您希望將Visual Studio集成用於源代碼控制，則可以查看VisualSvn ，它直接從Visual Studio中提供與TortoiseSVN的集成。 Visual SVN適用於您現有的Subversion文件夾，因此它不使用Visual Studio版本控制提供程序（恕我直言）。 而是與TortoiseSVN API對話並直接從文件存儲中獲取數據。 我沒有使用Visual SVN很長時間，但到目前為止它看起來不錯，雖然我已經習慣使用資源管理器進行源代碼控制，但它對於集成並沒有多大幫助。

有一件事情肯定更容易創建新項目 - 您可以使用Add to Subversion，VSVN將負責創建分支並為您檢出文件。

在IDE中查看文件的狀態非常好，如果您經常向系統添加新文件，這也很好，因為VSVN知道Visual Studio文件關聯並自動添加所有相關文件。