組織解決方案，項目和SVN

Question

我想在目錄結構方面幫助您在SVN中設置項目。我已經閱讀了關於這個問題的幾個答案，但由於我對此很陌生，其中大多數都很難理解。

我建立一個單一的庫，在其上其他幾個不同的項目依賴於：

我需要出口在MyLibrary的能力（頭，只.LIB）很容易通過第三方

MyLibrary1

使用

• 取決於外部庫，應該可以管理這些庫的不同版本！

MyLibrary2

• 取決於外部庫FMOD，GLEW，...

項目1，2，4，5，6 ...

• Depends中在MyLibrary1,2或兩者上
• 每個項目可能需要多個平臺的版本（osx，windows ...）

我想知道一個很好的方法來組織這個，請記住，我對此很新 - 一個更迂迴的答案會有幫助。例如，如果您編寫/ src之類的東西，請解釋應該進入的內容！我可以猜到，但我不敢肯定=）

//////////////////////////////// ////////////////////////////////////////////////// //////////////////////////

//編輯

我不能把這個變成一個評論，所以這裏有雲： @JN，感謝您的回覆廣泛，我想澄清一些東西，我希望我明白你的意思正確：

root 
    library foo 
     /branches   // old versions of foo 
     /tags    // releases of foo 
     /trunk    // current version 
      /build   // stuff required by makefiles 
      /tools   // scripts to launch tests ect 
      /data   // test data needed when running 
      /output   // binaries, .exe files 
      /dependencies // libraries that foo needs 
       /lib name 
        include 
        lib 
      /docs   // documentation 
      /releases  // generated archives 
      /sample   // sample project that shows how to use foo 
      /source   // *.h, *.cpp 

    program bar 
     /branches   // old versions of bar 
     /tags    // releases of bar 
     /trunk    // current version 
      /build   // stuff required by makefiles 
      /tools   // scripts to launch tests ect 
      /data   // test data needed when running 
      /output   // binaries, .exe files 
      /dependencies // libraries that bar needs 
       /lib name 
        include 
        lib 
      /docs   // documentation 
      /releases  // generated archives 
      /sample   // sample project that shows how to use bar 
      /source   // *.h, *.cpp 

1）在哪裏的*的.sln文件去？在/構建？

2）我是否需要將foo/source複製到bar/dependencies/foo/include？畢竟吧取決於foo

3）* .dll文件去哪裏？如果foo依賴於dll文件，那麼所有使用foo的程序都需要訪問相同的dll文件。這應該進入root/dll嗎？

Answer 1

您的問題有幾個層次：如何組織一個項目源代碼樹，如何維護不同的項目，如何維護這些項目的依賴關係，如何維護每個項目的不同變體以及如何包裝他們。

請記住，不管你做什麼，你的項目最終都會變得足夠大，使它不適應。在項目的整個生命週期中多次改變結構是正常的。當這種情況發生時，你會感覺到它不再適用：它通常是在設置困擾你的時候，而不是它的幫助。

---

1 - 維護每個項目的不同變種

還沒有變異爲每個項目，您不會維持parralel版本或分支機構解決幾個變種。對於可用於所有變體的每個項目/庫，有一個單一源樹。不要管理不同的「操作系統」，管理不同的功能。也就是說，有像「支持posix套接字」或「支持用戶界面」等變體。這意味着，如果有新的操作系統出現，那麼您只需選擇它支持的一組功能，而不是啓動新版本。

當需要特定的代碼時，創建一個接口（C++中的抽象類），並實現與之相關的行爲。這將隔離有問題的代碼，並有助於在將來添加新的變體。使用宏在編譯時選擇適當的宏。

---

2 - 維護每個項目

的依賴關係有一個特定的「依賴」文件夾中的每個子文件夾包含需要一個依賴一切（這是包括和子依賴）。在代碼庫不是太大的時候，你不必太在意自動確保所有的依賴關係都是相互兼容的，保存以備後用。

不要嘗試從svn層次結構中較高的根位置合併依賴項。正式將每個新版本交付給需要它的團隊，由他們自行更新自己的SVN部分。

不要嘗試一次使用同一依賴項的多個版本。那會很糟糕。如果你真的需要（，但儘量避免它，儘可能多的），分支爲每個版本的項目。

---

3 - 維護不同項目

我建議保持每個項目獨立存儲庫（SVN的他們仍然可能是相同的回購，但在分開的文件夾）。分支和標籤應該專門針對一個項目，而不是全部。儘量限制分支的數量，他們不能解決問題（即使使用git）。使用分支機制時，您必須並行維護不同的時間版本（而非變體），並在實際執行之前儘可能多地進行反擊，每個人都將從使用較新的代碼中受益。

這將允許強加安全限制（不確定如果可行與香草SVN，但有一些免費的服務器支持它）。

我建議發送電子郵件通知，只要有人向潛在感興趣的所有人提交項目。

---

4 - 項目源代碼樹組織

每個項目應具備以下SVN結構：

• 幹線（當前版本）
• 分公司（舊版本，沿用至今）
• 標籤（發佈，用於在需要補丁時不需要考慮太多而創建分支） 當項目變得更大時r，在子文件夾（例如分支機構/ V1.0/V1.1和分支機構/ V2.0/V2.1）中組織分支機構和標籤。

具有以下子文件夾的根文件夾：

• 編譯系統
• 工具（由您的makefile文件或其他需要的東西）（如果有的話（其中一些可能由VC自己創建） ，像XSLT工具或SOAP編譯器，腳本啓動測試）
• 數據（你需要在運行測試數據）
• 輸出（其中構建系統把二進制文件）
• 溫度輸出（由編譯創建的臨時文件，可選）
• 依賴
• 文件（如有）或生成的文檔）
• 發佈（生成的檔案見後）
• 樣品（一個小項目演示如何使用項目/庫）
• 源（我不喜歡拆分頭和.cpp，但是這是我的方式）
  • 避免子文件夾的層次太多，很難查找樹，名單更容易
  • 定義適當的每個文件夾的構建順序（沒有那麼必要的VC，但仍然）
  • 我把我的命名空間符合我的文件夾名稱（舊Java的習慣，但工程）
  • 明確規定需要在「公共」部分出口
  • 如果項目足夠大，可以容納多個二進制文件/ DLL的每一個都應該有自己的文件夾

不承諾你產生任何的二進制文件，只有釋放。二進制文件喜歡相互衝突並給團隊中的其他人造成痛苦。

---

5 - 包裝項目

首先，要確保包含SVN版本和日期的文本文件，有一個自動化的方式來做到這一點與自動道具。

你應該有一個腳本來產生版本（如果時間允許的話）。它會檢查所有提交的內容，生成一個新的版本號....創建一個zip/tar。gz歸檔您必須提交/歸檔，其名稱包含SVN修訂版，分支和當前日期（格式應該在項目間標準化）。歸檔文件應該具有運行應用程序所需的所有內容/在文件結構中使用庫。創建一個標籤，以便從緊急情況修復開始。