SVN Visual Studio存儲庫的工作目錄結構

我剛剛在我們公司爲我們的Visual Studio項目引入了SVN，並創建瞭如下所示的存儲庫（「解決方案」是Visual Studio解決方案，包含1..n個項目）：SVN Visual Studio存儲庫的工作目錄結構

/solution1/trunk/projectA/... 
       /projectB/... 
/solution2/trunk/projectC/... 
/customerX/solution3/trunk/projectD/... 
      /solution4/trunk/projectE/... 
          /projectF/...

現在，我有兩個選擇構建本地工作目錄：

選項A：讓每一個單獨的解決方案使用AnkhSVN的用戶結賬，導致結構是這樣的：

/solution1/projectA/... 
      /projectB/... 
/solution2/projectC/... 
/solution3/projectD/... 
/solution4/projectE/... 
      /projectF/...

或此，如果我告訴用戶手動創建一個子目錄customerX：

/solution1/projectA/... 
      /projectB/... 
/solution2/projectC/... 
/customerX/solution3/projectD/... 
/customerX/solution4/projectE/... 
        /projectF/...

優勢：用戶可以只檢出，他真正需要的解決方案。缺點：每個解決方案都需要單獨檢查/更新。

選項B：告訴用戶結帳使用TortoiseSVN是整個倉庫，導致這是完全一樣的存儲庫的結構：

/solution1/trunk/projectA/... 
       /projectB/... 
/solution2/trunk/projectC/... 
/customerX/solution3/trunk/projectD/... 
      /solution4/trunk/projectE/... 
          /projectF/...

優勢：它很容易爲「SVN更新一切」。缺點：用戶還擁有所有分支機構和標籤的本地副本。

問題：由於一些項目的解決方案（比方說，例如，該了projectA是也使用solution3庫），我們需要修復一個目錄結構，以確保共享的相對路徑在解決方案文件中是正確的。你推薦哪個選項，爲什麼？

編輯：感謝您的所有優秀的答案，特別是提svn:externals和強調一個好的庫設計的重要性。我結束了更新我的庫結構：

/trunk/solution1/projectA/... 
       /projectB/... 
     /solution2/projectC/... 
     /customerX/solution3/projectD/... 
          -svn:external to projectA 
       /solution4/projectE/... 
          /projectF/...

從而確保工作solution3 開發商只需要檢查solution3（而不是解決方法1）和解決方案可以簽出到任何目錄即，工作目錄不需要固定的結構。

來源

2009-11-02 Heinzi

好的問題，順便說一句... – David 2009-11-02 15:38:01

呵呵，這可能不是非常有幫助的，但是......都不是。:)

我會有trunk在最頂層，項目和解決方案在之下組織在一起，在一個扁平結構彼此並排。然後，我將使用解決方案目錄中的svn:externals屬性將適當的項目引入每個開發人員工作副本中的正確位置。

我整理東西這種方式的原因是，它給你要從你的選項A和您的選擇B.好處所以，如果開發商只是想看看一個單一的解決方案，他們可以自由地這樣做。同樣，如果他們寧願這樣做，他們也可以檢查整個行李箱（並且他們能夠在沒有獲得標籤和分支的情況下這樣做）。

此外，其單幹線的這一做法使得它容易得多標籤或分支整個回購，如果有的話，你需要做的。

來源

2009-11-02 15:24:26

+1。我沒有使用svn：externals屬性。 +1是給了我一些新的東西來探索那看起來很有前景的東西，它可能比我自己的解決方案更好。 – David 2009-11-02 15:59:06

樹幹在最高層...有趣的想法。我必須考慮這一點。 – Heinzi 2009-11-02 15:59:29

這與我們使用的結構相同。我不得不考慮svn：externals屬性，因爲我不熟悉它。 – 2009-11-02 16:08:15

對於它的價值，我們使用選項B.

我們也用龜SVN，而不是安赫SVN，因爲我們有我們的資源庫的結構好一點的靈活性，如果它不依賴於相同的目錄結構Visual Studio期望。

我最初嚴厲地反對這個，因爲我喜歡和TFS一起使用IDE集成，但在使用它幾天之後，我被賣掉了，更大的靈活性的交易比以前更重要的數千倍與IDE的集成。

編輯 - 添加

另外值得一提的是切換到我們目前的流程之前，我們映射出我們究竟是如何想打好我們所有的源代碼控制的。我們花了幾個星期的時間準確計劃它，在開關切換之前對它進行分析，但它在易用性和維護上得到了回報。

我們有一個像整體結構如下：

\內部Web應用程序

\互聯網Web Apps的

\企業的WinForms應用

\企業寡婦服務

\ Retail Location WinForms Apps

\零售定位服務

\共享

\跨平臺解決方案的文件。

每個主文件夾都包含許多不同的項目和解決方案。這些每個都有自己的分支，標籤和中繼線。因此，例如，如果我們有一個網上商店取景器，它可能在

\Internet\<our company name>.com\Store Finder\Trunk

這樣做的重要組成部分，是共享，因爲這包含了在所有其他分支使用的代碼。具有IDE集成功能的原因不適用於我們，因爲我們需要根級別的解決方案來實現此目的。相反，我們有適當的Sln文件，因爲我們都有完整的存儲庫副本，所以我們可以確保\ Shared目錄中任何項目的相對路徑在所有開發人員的PC上都是相同的。

我提供了上述內容，而不是告訴你如何構造你的代碼，只是爲了給你提供一些想法，並強調在繼續之前徹底規劃它的重要性。

你需要花一些時間來問一些問題，比如「如果我像Y一樣佈置它，我可以做X嗎？」。你的情況對你的團隊和公司來說是獨一無二的。

來源

2009-11-02 15:16:41 David

感謝您的詳細解釋！ – Heinzi 2009-11-02 16:02:10

選項A - 您不希望每次都拉動整個存儲庫（所有標籤和分支），它會鼓勵用戶將整個存儲庫視爲一個單一的實體，你希望他們在解決方案和標籤/分支方面進行思考。

您通過在適當解決方案的「根」中引用它們作爲外部對象來解決共享項目。這意味着你可能有多個相同的項目在你的硬盤上出現，但這是可管理的。

還有更多的蠅頭位上這裏的主題： HowTo: Reference external SLN files with TeamCity

來源

2009-11-02 15:24:25 Murph

我會使用扁平的目錄結構，並使用svn:externals場所在包括共享項目的強烈第二菲爾攤位溶液。

主要的原因是，這給了你自由去耦不同使用共享項目客戶項目如何，如圖書館，被更新。使用您提出的結構，所有其他客戶端項目使用的共享庫項目只有一個副本：因此，所有使用共享項目的項目都必須看到相同的版本。這並不總是可取的。

有時，變化到共享庫將需要使用該庫在客戶端代碼的相應變化。根據你提出的結構，這種改變將要求你立即更新圖書館的所有客戶項目，或者承認許多客戶項目可能會被打破。

對於使用庫的每個客戶端項目使用svn:externals意味着每個客戶端都將擁有其工作副本中的該庫副本（但磁盤空間很便宜）。但是，存儲庫中仍然有一個庫項目的副本（客戶端項目只是引用它的不同版本），因此特定的客戶端項目可以繼續使用舊版本的共享庫，或者可以更新更新svn:externals屬性），以使用更新的版本

總結：

對你提出的佈局：提交更改庫項目立即改變所有使用該庫項目的所有客戶端的項目得到更新圖書館，他們是否希望他們還是沒有。

隨着svn:externals，提交更改庫項目隻影響溴化鋰ary項目。每個客戶端項目都需要額外的提交來更新svn:externals屬性，以引用該庫的較新版本（可以將其與客戶端項目代碼的對應更改一起提交）。所有客戶項目都可以更新圖書館，但只有在他們明確要求時才能獲得。

來源

2009-11-02 16:21:19

SVN Visual Studio存儲庫的工作目錄結構

回答

相關問題