SVN項目結構

我們正在從VSS轉向SVN並且正在討論項目結構。我們正在討論下面顯示的兩個建議。SVN項目結構

由於項目發佈版本與標籤綁定，開發人員只需對該標籤執行更新即可開始工作，因此第1號似乎更易於開發支持。

2號確保所有項目和依賴項可以獨立開發，但構建一個特定的發佈版本意味着知道項目的標籤和所有它是依賴項。

兩者之間是否有明顯的比較優勢？這兩個結構的任何陷阱？或者那裏有更好的結構？

 
1. 
Development 
    + trunk 
    Project1 
    Project2 
    Dependency1 
    Dependency2 
    Dependency3 
    + branches 
    + tags 

2. 
Project1 
    + trunk 
    + branches 
    + tags 
Project2 
    + trunk 
    + branches 
    + tags 
Dependency1 
    + trunk 
    + branches 
    + tags 
Dependency2 
    + trunk 
    + branches 
    + tags 
Dependency3 
    + trunk 
    + branches 
    + tags

來源

2011-01-07 user481779

感謝您的回覆。對於＃2，我們如何將項目版本和它的依賴版本聯繫在一起？在創建標籤的時間點＃1，您正在創建標籤的項目，它的依賴關係被認爲是兼容的。 – user481779

＃2你使用svn：externals。基本上，它是你的項目中的子目錄，與特定的svn結帳相關聯。對於＃1，當依賴關係想要與其中一個使用它的項目「失去同步」時，或者兩個（或更多）項目無法在相同的特定版本的依賴關係上進行協調時，會遇到問題。 –

一般來說，我建議讓項目保持分開，儘可能有意義（您的第二個選項）。這通常會促進重用。（如果我只想使用Dependency2，我不需要帶一個完整的項目來實現它。）

但是，您必須明智地瞭解您的依賴關係是如何實現的。例如，如果Dependency2是，只有將成爲Project1的依賴項，那麼它應該只存在於Project1的源結構中。（注意：我並不是說爲依賴關係分開了獨立的分支和標記 - 我的意思是它位於不同的包或Project1中的另一個子項目中。）

如果要將項目設置爲組織中的可重用庫，然後將它作爲一個單獨的項目完全使用，這樣就不會引入不必要的協同依賴關係。而且，我會鼓勵你的開發團隊不要檢查依賴並與之協作。相反，構建依賴關係並將它們用作二進制庫。通過這種方式，檢出項目的人將始終擁有應用程序所需的最新庫依賴項。如果需要更新，那麼您可以擔心檢查依賴關係並構建它。（或者甚至更好，必須向項目團隊可以發佈最新的庫作爲二進制文件的位置。）對項目的版本

更新和依賴 如果用＃2的路線走，並有單獨的項目和依賴關係，你的版本控制變得非常簡單。這是它如何工作的概述。

團隊A正在Project1上工作。
B隊正在研究Project1依賴的Dependency1。
每當團隊B完成他們的工作，他們就構建了一個Dependency1（一個二進制 - 也許是一個DLL，或一個庫，或沿着這些線）的版本。他們現在也可以標記他們的項目。二進制名稱可能是：Dependency1-v1.0.0
團隊A獲取Dependency1-v1.0.0的二進制版本並將其包含在他們的項目中。（通常，二進制文件保存在/ lib文件夾或類似項目中的文件夾中。）
每當團隊A完成工作時，他們都可以發佈他們的項目並標記他們的項目。

需要注意的是，在任何時候，做A隊退房源代碼依賴關係1，並把它納入自己的項目。這樣可以使兩個項目的開發保持分離，以便開發團隊之間有自主權。團隊A可以使用二進制文件，只要他們喜歡就可以。如果他們想要更新的版本，他們會從B隊獲得最新版本。

這個過程與您使用來自外部來源的庫時所做的並無太大區別。你無法控制他們如何版本化他們的庫，所以你只需要抓住你需要的項目並在需要時進行更新。您將二進制文件保存在您自己的項目結構中，以便始終可以依靠它。

來源

2011-01-07 20:01:39 JasCav

非常感謝JasCav。我在帖子中添加了一條評論，以瞭解將項目和Dependency版本捆綁在一起的過程。 – user481779

@ user481779 - 更新了我的答案。如果這可以幫助你，請確保你註冊或接受答案。我注意到你現在的比例很低（25％）。如果人們知道你要獎勵他們，你會得到更好的答案。 – JasCav

我會親自去＃2。我在我以前的公司做過這件事，而且工作得很好。它隔離了每個項目，因此您可以輕鬆查看其分支和標記的歷史記錄，而無需額外的工作。只需簽出一個項目並獲取所有分支，標籤和主幹，在追蹤本地差異時也是一項很好的功能。

來源

2011-01-07 19:58:41

非常感謝馬克。我在帖子中添加了一條評論，以瞭解將項目和Dependency版本捆綁在一起的過程。 – user481779

-1

如果所有項目都是同一解決方案或產品的一部分，那麼我會採用方法1。

我使用下面的結構：

TRUNK 
--Build 
--Product 
----Source 
------Project1 
------Project2 
------Project3 
----Test 
--ThirdParty

的第三方目錄是用於非源代碼依賴性諸如圖書館或API。

我的指導植根於一位新開發人員，他能夠從Trunk獲取最新信息，並獲取他們需要立即構建產品的一切（並且我指的是一切）。追查參考文獻是一個很容易避免的時間浪費。

來源

2011-01-07 20:07:47 Derek

謝謝德里克。除了依賴於共享庫之外，我們的項目與其他項目無關。 – user481779

-1

我的經驗是它只是一個約定的問題。而且SVN Book也沒有問題。

在其中一個項目中，團隊正在使用ANT構建並更加強調扁平結構。我們的方法是＃2。使用一個主構建腳本。當我正在研究這個問題時沒問題，我們沒有問題。

當前項目涉及到Maven構建，所以在代碼默認情況下有＃1結構與一個父項，並在其下，依賴項和模塊化項目。在SVN中，我們遵循方法＃1。但是，如果一個全新的項目即將開始，我們將在佈局中混合＃1和＃2。這樣的事情：

Project1 
     trunk 
      project1A 
      project1B 
      dependency1C 
      dependency1D 
     branches 
     tags 
    Project2 
     trunk 
      project2A 
      dependency2B 
     branches 
     tags

總結，我想保持我的存儲庫在邏輯上分開。所以，要回答你的問題 - 我寧願採用方法2。

編輯＃1：SVN圖書網址是固定

來源

2011-01-07 20:24:50 Nishant

@downvoter請解釋一下。這是一個關於約定的問題 - 不可能有正確或錯誤的答案。投票中沒有任何意義。 – Nishant

去與＃2：

Project1 
    + trunk 
    + branches 
    + tags 
Project2 
    + trunk 
    + branches 
    + tags 
Dependency1 
    + trunk 
    + branches 
    + tags 
Dependency2 
    + trunk 
    + branches 
    + tags 
Dependency3 
    + trunk 
    + branches 
    + tags

與必須參考其他項目，檢查出部分上"SVN Externals"項目。這使您可以將依賴項的特定SVN修訂版設置爲另一個項目中使用的值。

來源

2011-01-07 20:36:29

我知道我遲到了......這是否意味着你在內部使用SVnExternals 'Project1-Trunk-whatever'鏈接到'Dependency1-trunk-whaterver'？ – BlueChippy

您有想在項目中引用其他源代碼的想法;但是，還有其他解決方案。大多數IDE能夠將源代碼分發（通常是zip）附加到已編譯的JAR。您可能希望僅將這兩個項目分割開來，並用Maven或Ivy管理它們之間的相互依賴關係。經過一些設置後，它確實提供了不僅僅依賴管理。它提供了一個自動化的世界，能夠以更少的人力完成更多的工作。 –

這篇文章的主要觀點是，「每個項目一個倉庫」比「一個包含依賴項的倉庫」更受青睞，主要是因爲它允許您在監視倉庫時減少構建工作的範圍。存儲庫更改觸發器意味着構建該項目，並且不會構建任何不受此更改影響的項目。這意味着更少的測試（因爲測試永遠不會重新測試一個沒有改變但重建過的庫），減少編譯時間，並且更好地將未來問題控制到更小的代碼區域。 –

謝謝大家幫助我理解這個好多了！

@JasCav，我特別感謝您解釋如何思考如何「依賴」特定的依賴關係。我有兩個，所以我認爲結構暗示將是：

 
Project1 
    + trunk 
     SubPrjFor_Prj1 
     LibraryExternalRefs 
      Dependency1_DLLOnly 
      Dependency2_DLLOnly 
      Dependency3_DLLOnly_NOT_SHARED_UsedOnlyByPrj1_ONLY_HERE 
     LibraryWithSource 
      Dependency4_UsedOnlyByPrj1_NOT_SHARED 
       Source_SubFolder1 
       Source_SubFolder2 
    + branches 
    + tags 
Project2 
    + trunk 
     SubPrjFor_Prj2 
     LibExternalRefs 
      Dependency1_DLLOnly 
    + branches 
    + tags 
Dependency1_UsedByBothPrj1Prj2 
    + trunk 
      Dependency1_DLLOnly 
    + branches 
    + tags 
Dependency2_UsedByPrj1SoFar 
    + trunk 
      Dependency2_Source_SubPrj1 
      Dependency2_Source_SubPrj2 
    + branches 
    + tags

當然，我已經省略了幹線/分支的匹配結構。

ps @JasCav，對於沒有投票給你，也沒有把這個項目置於你的評論之中，我表示歉意。我顯然沒有要點去做這些事情，這對我來說沒有多大意義。我以爲登錄會讓我評論，因此跟蹤Stackoverflow項目的利益，但我猜不是。

編輯：固定格式並將示例擴展爲4個依賴項。

來源

2011-01-12 15:03:19 AnneTheAgile

這些用戶建議每個團隊都有一個存儲庫，而不是隻保留一個存儲庫，如所有這些結構所示，在另一個帖子VSS to SVN - Repositories上。這樣SVN修訂號碼只會在個人團隊提交後纔會增加。

有沒有人試過這種方法？是否有額外的開銷工作？

我想用最少量的SVN管理工作保持代碼庫清潔，就像在我的情況下我可能會這樣做:)。

來源

2011-01-12 16:28:06 AnneTheAgile

SVN項目結構

回答

相關問題