我的公司很難找出管理我們的構建，發佈和分支的最佳方法......我們的基本設置是我們有4個應用程序，我們維護2個WPF應用程序和2個ASP。 NET應用程序中，所有這些應用程序中的4個共享公用庫，因此它們當前都位於一個文件夾/ trunk/{app1，app2，app3，app4}中。.NET依賴管理和標記/分支
這使得很難分支/標記單個應用程序，因爲您在同一時間分支所有4個應用程序，所以我們希望將它分成{app1，app2，app3，app4}/{trunk ，tags，branches}但是我們遇到了將共享庫放在哪裏的問題？
我們不能將共享庫設置爲SVN外部因爲然後當你分支/標記分支仍然引用幹線共享庫而不是讓它們分支。
任何提示？想法？
我們目前正在使用svn和cruisecontrol.net。
編輯：共享庫經常改變，因此我們不能使用它們作爲svn外部樹幹，因爲我們可能會改變它們在分支中。所以我們不能將它們用作二進制引用。
當靜態構建庫而不是包含源代碼時，它也很難測試和調試。
我想這一切都取決於共享庫的穩定性。我最喜歡將共享庫視爲他們自己的項目，像其他項目一樣在CruiseControl中構建。然後，四個主要應用程序將具有對共享庫的二進制引用。
這種方法的主要優點是現在共享庫是靜態的應用程序的穩定性。對庫的更改不會影響應用程序，除非它們將二進制文件顯式更新爲新版本。分支帶來二進制引用。你不會有這樣一種看似無害的改變打破了其他三個應用程序的情況。
我同意@Brian Frantz。沒有理由不把共享庫視爲他們自己的日常構建項目，並且您的項目在日常構建中對二進制文件依賴。
但即使你想保留它們作爲源依賴項並使用應用程序構建它們，爲什麼SVN外部方法不適合你？當你分支特定的應用程序時，不需要分支共享庫，除非你需要爲該分支單獨拷貝它。但這意味着，它不再是共享庫了，對嗎？
共享庫現在經常變化，這就是爲什麼我們不能使用它們作爲svn外部的主幹，因爲我們可能會在分支中改變它們。所以我們不能將它們用作二進制引用。 我們分支它的原因是因爲我們可能會進行重要的改變，影響共享庫，但我們不想破壞其他項目，直到更改在分支中被修復和測試，然後當我們合併它時回到主幹中，我們會在其他應用中修復對它的呼叫。 – sontek 2009-12-14 19:30:29
這是一個災難食譜。當你分支你的兩個應用程序並且爲這兩個應用程序分支共享庫時會發生什麼？合併共享庫變回可能（可能會）成爲物流的噩夢。 （在那裏，這樣做:-)） – 2009-12-14 20:01:51
好吧，顯然這是一個問題，但我們必須依靠開發人員之間的良好溝通，應該有很少的時間他們必須在相同的確切線上工作，如果他們接觸相同的線條和它們相互衝突，我們有差異工具來弄清楚什麼地方出了問題，它只是團隊開發的一部分:) 我認爲它更好地讓代碼分支，所以他們改變的所有*該分支並且不會影響其他開發者，我們分支的唯一時間是我們將要進行突破性更改:) – sontek 2009-12-15 03:16:54
我已經嘗試過多年來解決這個問題的幾種方法，我可以誠實地說沒有最好的解決方案。
我的團隊目前處於一個巨大的發展階段，每個人都需要在任何特定時間使用最新最好的共享庫。在這種情況下，我們在每個人的C：驅動器上都有一個名爲SharedLibs \ Latest的文件夾，它會自動與每個共享庫的最新開發版本同步。每一個應該從firehose喝酒的項目都有對這個文件夾的絕對文件引用。隨着人們推出共享庫的新版本，各個項目最終都會透明地選擇它們。
除了最新的文件夾之外，我們還有一個SharedLibs \ Releases文件夾，它具有爲每個共享庫的每個版本命名的文件夾層次結構。隨着項目逐漸成熟，並進入發佈候選階段，共享庫引用被指向這些穩定的文件夾。
這最大的缺點是，這個結構需要適合任何項目建設。如果有人想在10年後開發應用程序，他們將需要這種結構。需要注意的是，這些文件夾也需要存在於構建/ CI服務器上。
在此之前，每個解決方案都有一個位於源代碼管理下的lib文件夾，其中包含二進制文件。每個項目所有者的任務是宣傳新的共享dll。由於大多數人擁有多個項目，因此仍然處於非穩定階段的項目中，通常會出現裂縫。另外，TFS似乎沒有很好地跟蹤對二進制文件的更改。如果TFS跟蹤dll更好，我們可能會使用共享庫解決方案/項目，而不是我們現在採用的文件系統方法。
看看Apache NPanday + Maven Release + Nexus Repository Manager（我是一個提交者;而且用戶只是要求我們讓NPanday更明顯，因爲它太棒了:-)） – 2011-11-09 15:27:27
你能否澄清爲什麼你不喜歡同時分支所有四個應用程序？
這使得它很難分支/標籤的單個應用程序，因爲你是在同一時間
我通常把我所有的項目直屬樹幹，你正在做的所有分支4。然後，當我創建一個發佈分支或一個功能分支時，我只是忽略了隨之而來的其他項目。請記住，副本很便宜，所以它們不會佔用服務器上的空間。
具體而言，這裏就是我會制定出你所描述的源代碼樹：
服務器上的副本很便宜，但是在開發者計算機上籤出和複製並不便宜，大多數開發人員喜歡將整個回購檢查出來，以防他們必須與某人在某個分支上工作，他們已經將其撤下了，但這會在永久你有幾個分支和標籤正在進行。 但到目前爲止，這似乎是最好的解決方案:) – sontek 2009-12-15 19:45:59
在你的情況下，我會檢查出幹線或單個分支，無論我正在工作。然後使用開關在另一個分支上工作。我可能會檢查兩份工作副本，因此我可以在我的主要工作分支上留下一個副本，並在其他分支上執行小型工作時使用另一副本進行切換。 還有其他需要考慮的問題是淺層結賬：從根目錄檢出整個存儲庫，但不要將結帳遞歸到分支，直到您需要爲止。我覺得這更煩人，因爲擺脫結賬分支是一件麻煩事。 – 2009-12-16 01:24:33
我同意這是正確的方法。保持整個回購檢查的開發者是一種可以改變的行爲 - 沒有理由有一個不合標準的解決方案來滿足什麼是有效的懶惰，恕我直言。除此之外，當有人正在實驗WPF 1.1分支時，我不想等待所有這些更新，而只是試圖在一個特定的分支上工作。 – gregmac 2009-12-31 00:25:39
我們踢了一個開源項目，試圖解決這個問題。如果有人有興趣在評論這或有助於它，它在：
查看[Maven alternatives的問題]（http://stackoverflow.com/q/652583/4794），瞭解用於管理二進制相關性的.NET工具列表。但是，我認爲使用這些工具來管理第三方二進制文件可以獲得最大的收益。就我個人而言，如果我的團隊編寫它，我更喜歡從源代碼構建圖書館 – 2011-11-09 18:16:30
它給你dependeny管理（傳遞解決方案），強大的版本控制支持以及14+版本控制系統（包括SVN）的自動標記/分支功能。
給我一個提示，如果我要詳細說明一下。
我認爲你不可能避免版本化並將你的共享庫作爲單獨的工件分發，但Maven可以幫助你做到這一點！在源
你可以做百達招數把一切在一個解決方案推出了:-)
樣本工作流程
如果你想提供壓縮包作爲你的版本的輸出，Maven Assembly Plugin將幫助你做到這一點。
您可以在獨立模式下使用Apache/IVY。
http://ant.apache.org/ivy/history/latest-milestone/standalone.html
我需要強調的 「獨立」 模式。如果你是谷歌的例子....你會發現很多（不是獨立的）。
基本上，IVY基於這個前提。
您發佈二進制文件（或任何類型的文件，但我會說，從這一點來說，二進制文件）......作爲小二進制包。
下面是PSEUDO代碼，不要依賴我的記憶。
java.exe ivy.jar -publish MyBinaryPackageOne.xml --revision 1.2.3.4（< <其中將.xml指N個文件組成一個包。））
「包」僅僅意味着一組文件。你可以在一個包中包含.dll和.xml以及.pdb文件（我使用DotNet構建的程序集）。管他呢。 IVY是文件類型不可知的。如果你想把WordDocs放在那裏，你可以，但是sharepoint對文檔更好。
當您對代碼進行錯誤修復時，您會增加修訂版本。
java.exe ivy.jar -publish MyBinaryPackageOne.xml --revision 1.2.3.5
再後來，你可以從IVY獲取你想要的東西。
java.exe ivy.jar -retrieve PackagesINeed.xml
PackagesINeed.xml將包含有關所需軟件包的信息。
像 「我希望MyBinaryPackageOne的版本「1.2+」 （定義在XML中）
在構建框架的二進制文件......你發佈到IVY。 然後，當你開發和建立你的代碼...你從IVY中檢索。
在NUTSHELL中，IVY是FILES的存儲庫（不是源代碼）。
常春藤然後成爲您的二進制文件的權威來源。
沒有一個「嘿，開發人員 - 喬有我們需要的二進制文件」有點混亂。
.......
優點：1。 你不要讓你的二進制文件的源代碼控制。 （並且因此不會BLOAT您的源代碼管理）。 2.您有一個明確的二進制文件來源。 3.通過xml配置，您可以說出庫需要哪些版本。 （在上面的例子中，如果MyBinaryPackageOne的版本2（2.0.0.0）發佈到IVY（讓我們假設破壞1.2.xy的更改）...那麼你沒問題，因爲你在你的retrieve（xml配置文件）...。那你只需要「1.2+」因此，你的項目將忽略任何2 + ...除非你改變了配置包
高級：。 如果你有一個構建機器（CruiseControl.NET例如）....你可以編寫邏輯在每次構建之後發佈你的（新建的）二進制文件到IVY （這是我所做的）。
我使用SVN修訂版作爲內部版本號中的最後一個數字。 如果我的SVN版本是「3333」，那麼我會跑是這樣的：
java.exe ivy.jar -publish MyBinaryPackageOne.xml --revision 1.2.3.3333
因此每當檢索包修訂「1.2.3+」 ....我會得到最新建立。 在這種情況下，我會得到包的版本1.2.3.3333。
很遺憾，IVY是在2005年開始的（好吧，這是個好消息）......但是NUGET直到2010年纔出來？ （2011？） 微軟在這一個IMHO上落後5-6年。
我永遠不會回到將二進制文件放在源代碼控制中。
IVY非常好。這是時間證明。它解決了依賴管理的問題。
是否需要一點時間才能適應它？是的。
但它最終值得。
我的2美分。
.................
但想法＃2是 瞭解如何使用的NuGet與本地（如in..local貴公司）倉庫。
這和IVY差不多。
但看了NUGET，我還是喜歡IVY。
共享庫現在經常變化，這就是爲什麼我們不能使用它們作爲svn外部的主幹，因爲我們可能會在分支中改變它們。所以我們不能將它們用作二進制引用。 – sontek 2009-12-14 19:29:11
如果要添加到共享庫中，我會將新代碼放入分支中的應用程序中，然後僅在其他應用程序需要時纔將其移至共享庫。在應用程序中進行開發直到完全測試，然後僅在需要時纔將其展示給其他應用程序。 可能不應該更改錯誤修復以外的共享庫 - 現有類/方法的功能/接口通常應該保持不變。打開/關閉原則 - 增加功能，不改變現有。 – 2009-12-14 19:36:18
這些共享庫是我們應用程序的核心，如果發現錯誤或出現新功能，它需要更改。 例如，其中一個共享庫是兩個應用程序中使用的一些asp.net用戶控件，因此最近我重新設計了信用卡/付款控制以添加付款計劃功能（付款計劃是一項新的業務需求）。我顯然不想改變主幹中的付款控制，因爲這會干擾所有人的工作。所以我需要分支，直到我得到它的工作，然後將它合併回主幹。 – sontek 2009-12-15 03:14:00