我開發了各種應用程序，並且在這些應用程序中重複使用了3-4個雜項庫（一個用於數學，一個用於數據庫功能等）。源代碼管理佈局
目前我有一個主源代碼目錄，每個項目都作爲頂級目錄（包括我的幫助程序項目）。並且每個需要助手的項目都將整個項目添加爲解決方案中的參考（而不是針對庫）。這允許對助手庫進行快速調試/更新，但是很快就會變得麻煩，因爲我總是需要重新構建幫助程序，並且可以對較早的程序使用的接口進行重大更改。
所有這些都存儲在Subversion存儲庫的trunk目錄中，當我分支特定的目錄時，我創建了一個大規模的分支等。這很難保持向後兼容性以及剪切代碼大小和本地大小的存儲庫。
處理這些情況的最佳方法是什麼？你如何佈置你的各種項目。
您是否將每個項目放置在自己的Subversion存儲庫中？或者，您是否使用一個具有多個頂級項目和其下的trunk/branch /標籤的存儲庫？
你如何參考替代項目？你只是編譯這些和參考數據？
請參閱我在Projects folder structure recommendation和How do you organize your version control repository?答案不必浪費時間。
爲了您的具體問題，這個問題是管理項目間的依賴關係。答案是他們的版本 - 每一個依賴於另一個項目應該只依賴於從該項目（或最接近的等效如果沒有編譯的程序/庫）的二進制交付，並且交付應在每個這樣的參考版本。當然，您首先需要確保每個項目都生成一個和一個二進制可交付成果（或等價物）。
通過僅在從另一個項目二進制交付依賴，你使每個項目獨立，大大緩解了維護，因爲其「打造界面」是一個單一的文件。到達另一個項目的源代碼/構建就像進入圖書館實施的中間階段=很多問題。
通過版本控制每一個項目，你可以修改代表另一個（新的）項目的特定項目的來源，但並不影響任何使用它的其他老項目。實際上，每個項目都會成爲PRODUCT。像任何產品一樣，您應該管理其版本以及與其他產品的兼容性。
我從來沒有使用過顛覆，但我可以在存儲庫問題之外提供一些信息。我的答案是真的取決於scenairo和公司。對於我參與的最大項目之一，我們使用了以下結構。該項目由大約20個核心組件組成，這些核心組件將在各種應用程序中共享。我們也在使用TFS。
我們定義了一個通用TFS項目，其中包含一個主構建解決方案來構建公共項目中的所有項目。當我們建立時，我們會發布二進制文件。
然後，我們爲每個業務部門及其各種應用程序（每個BU可以有1到n個項目/應用程序）提供TFS項目。然後，我們設置應用程序以使用文件引用將二進制文件拖放到他們自己的項目中。在這種情況下，業務部門將公共圖書館視爲第三方產品。
在不太正式的情況下，我們會讓業務單元直接引用構建輸出（他們會被檢查回到源代碼管理系統中）。這允許業務部門在編譯完成後獲得新版本，但正如您所指出的那樣引入了兼容性問題。這是讓他們完全孤立幫助的地方。
我的可重複使用的庫是在單獨的項目中開發的，在源代碼庫中有單獨的源代碼目錄（我使用TFS，但它應該適用於SVN）。我在一個公共位置發佈這些庫的版本 - 在我的情況下，通過DFS引用網絡共享。根據需要，將已發佈庫的引用添加到我的其他項目中。有時我會使用版本控制（命名版本），如果我發現由於某種原因需要維護多個版本的庫。從某種意義上說，我將它們全部視爲第三方組件，不要直接引用它們的項目。
我認爲你需要一個共同的項目seperete解決方案，並有他們自己的構建過程。我會將它們作爲主項目中的二進制引用鏈接起來。如果您有pdb文件，您仍然可以通過使用visual studio來調試此代碼。我覺得這個規模的唯一途徑，或者你有保留這些問題
一想思考的是把所有的共享庫在一個位置，並有當地項目創建一個ext目錄把所有的共享鏈接的二進制文件。然後，您可以編寫腳本來檢查是否有更新版本等，以避免手動升級
不要把所生成到源控制系統，任何東西：它不是源。對輸出二進制文件進行版本控制是很好的，所以不要用直接的未版本化依賴關係（它引入了像你說的那樣的兼容性問題）來妥協。半步只會增加成本，但不會授予收益。 – 2008-12-01 03:19:14