好的，我明白一個項目的存儲庫的trunk/tags/branches thingy。svn：早期在開發過程中的模塊組織
現在我們假設我有一個主要項目和一些較小的輔助模塊/插件/工具/腳本等。在早期階段有很多重命名，重組等等，其中一些死於早逝因爲他們無處可去。在組織非常穩定之前，將特定模塊粘貼到主幹中是沒有意義的。 （根據svn設計，複製到主幹是「便宜」）
在開發過程的早期，哪裏可以放置一個小模塊（比如說「FooModule」）？
沒有任何人有經驗，組織顛覆庫以類似的方式？什麼爲你工作？
我不知道如果我的組織結構適合您的需求，但我採取了一個非常不同的方法比軀幹/標籤/分支模型。詳情請看http://www.mattwrock.com/post/2009/10/10/The-Perfect-Build-Pard-2-Version-Control.aspx。
這裏是我們的結構：
/prod
/prod/app1/20090903
/prod/app1/20090917
/prod/app2/20090903
/sandbox
/sandbox/users/mwrock
/staging
/staging/app1
/staging/app2
/trunk
/trunk/libraries
/trunk/desktop
/trunk/docs
/trunk/services
/trunk/sql
/trunk/testing
/trunk/thirdparty
/trunk/web
在這裏，我們有以下的根文件夾：
幹線：這個擁有適合 融入主線最新的代碼版本。有 是所有 項目和團隊共享的單一主幹。開發人員只有 必須檢出這個單一文件夾 ，他們有他們需要的一切。
沙盒：這些是用於分支要 長期運行變化的個人發展方面保持獨立於軀幹，直到 他們準備合併回 主幹。
分期：這是最後的QA/UAT區域。幹線在這裏複製一次 開發被認爲是穩定的 並準備好進行最終測試。這 保護其他團隊致力於發展的發展 。 當一個版本是在這個階段，你 不從 別人進入你的代碼庫，想不明的提交。
PROD：這包含了產品發佈。每個應用程序都有其自己的 文件夾下，並督促各 釋放有其發佈的 日期命名的文件夾。分支 分支在部署時被複制到這些發行版 標籤，並且它們 代表在 發行時的代碼的快照。產品區域是 歷史記錄，究竟是什麼 被髮布以及何時發佈。
/branches/dev/FooModule將是最明智的方法，如果你真的不想從它的啓動恕我直待從後備箱。這就是開發分支的目的（除非通常情況是相反，代碼從主幹中複製，然後最終返回主幹）。
我肯定會避免像你給出的其他兩個例子那樣不尋常的根路徑名。您將在Version Control with Subversion中找到進一步的注意事項。
當我自己接觸到這類東西時，我傾向於使用一個完全獨立的存儲庫來保存主存儲庫中不必要的修訂混亂。
我對每個應用程序都有樹幹，標籤，分支的愛好者。在這樣的設計中，你可以爲沙箱做任何你想做的事情。
app1/
trunk/
tags/
branches/
app2/
trunk/
tags/
branches/
sandbox/
trunk/
tags/
sure_you_could_keep_the_parallelism_up_here_but_is_there_really_any_need/
人們會鬥嘴左右來回做這種方式或根級幹線，標籤，分支方式的利弊，但這樣一個強大的優勢在於，合併和檢出的痛苦要少得多。 （很多人忽視了這個結構，因爲他們看到他們的項目在應用程序之間共享代碼）當我們需要這樣的代碼共享時，我們使用svn：externals取得了一些成功，真正好的是甚至可以打破公共庫如果你使用外部鏈接來連接標籤，這將會是沒有問題的，這會在公知庫已經工作的時候凍結公共庫。）
如果用戶在分支/標記他們的代碼時不忘記更新他們的svn：externals，那很好。 – Vladimir 2009-10-22 19:22:51
@Vladimir如果將svn external設置在項目的主幹上，並且爲分支/標記複製了主幹，則不需要更新外部;它被複制。外部需要更新的唯一時間是如果重要的是要鏈接到另一個項目的最新版本。除非其他項目包含關鍵的共享標準，例如序列化/反序列化例程，否則這通常並不重要。 – 2009-10-23 22:03:21
這是一個非常有趣的問題，因爲起步權有很多好處（模塊化，低耦合...）。無論如何，這是我會怎麼開始：
1）把所有的東西放進後備箱：
http://svn/application/trunk/application
2）如果可以的話，早早就開始了代碼分成模塊
http://svn/application/trunk/application1
module1
module2
3 ）如果一個模塊是穩定的，將其上游移動到它自己的存儲庫中：
http://svn/module1/trunk
4）最後，當你有幾個穩定的模塊es和應用程序，您可能會以
http://svn/application1/trunk
http://svn/application2/trunk
http://svn/module1/trunk
http://svn/module2/trunk
每個應用程序/模塊都有其自己的發佈週期。
或者，（如果你問我很好的組織），你可以看看什麼Spring框架是做
http://svn/application1/trunk
http://svn/application2/trunk
http://svn/framework/trunk/module1
http://svn/framework/trunk/module2
我建議不要分裂代碼放到後備箱/每個模塊的分支，在至少在項目開始時：只要開始分支（而不是在主幹上工作），就不能再使用其他模塊主幹的頭部了：您必須同時或工作地分支所有項目與特定版本（1.0而不是SNAPSHOT）。我不認爲我很清楚，但讓我知道是否必須以不同的方式解釋它。
我不能編輯大衛的帖子，但我想提及svn:externals：從發佈的角度來看，它們非常危險（imo）。這裏的噩夢場景：
讓我們假設你svn:externals你的應用程序中的一些模塊代碼;爲了它，讓我們假設該模塊的Subversion版本是1000。您創建一個分支，製作一個發佈並將其發送給客戶。
時間流逝，幾個月/幾年後，客戶要求您解決應用程序中的問題。您檢查分支並開始svn updating該項目。不幸的是，鏈接的模塊已經發生了很大的變化，現在版本爲23456.現在應用程序甚至不再編譯。
當然，你必須這樣做，所以改變svm:externals指向確切的版本（1000），當你分支。如果您必須更改模塊的代碼，則必須現在指向在版本1000處爲模塊創建的分支的頭部。
大量不必要的工作，這就是爲什麼我會強烈阻止使用外部任何大型項目。
如果您有與svn:externals良好的經驗，我都耳聞。
只需要考慮一點：如果你打算讓你的項目通過Ohloh進行公開和追蹤，你最好從/ trunk中產生大部分東西。 – jldupont 2009-10-22 19:01:59