我目前正在測試服務器上安裝和配置一個開源項目。我已經受過良好的源代碼控制培訓，並且我希望確保我所做的一切都得到妥善管理（包括我，唯一的開發人員/管理員和未來的維護人員）。開源項目可以通過源代碼下載或通過svn checkout獲得。現有開源項目實施的源代碼管理/管理
我想擁有自己的源代碼控制版本的項目。我不打算更改（java servlet）代碼（如果有的話），但有一些配置，XML文件，XSL，CSS等等，我絕對想要受到源代碼控制。
我應該繼續，只是讓我自己的本地存儲庫的所有源代碼？我應該只嘗試控制需要更改的文件嗎？在這種情況下，我會希望目錄結構匹配，所以我可以直接檢出到構建目錄。
有兩次檢出到同一個目錄樹將無法正常工作。如果您簽出源代碼並嘗試檢查OSS項目源，那麼它們共有的任何目錄都將失敗，並說它已經是另一個項目的工作目錄。
如果您可以將css，xml，xsl等收集到一個公共目錄中，可以將它們放在您自己項目的svn中的單個目錄中，然後將它們簽出到OSS工作目錄中的一個目錄中項目。
〜/工作=>的svn：// samhoice /項目/主幹
〜/工作/ osscomponent =>的svn：// osshost /項目/ latesttag
〜/工作/ osscomponent/config => svn：// samhoice/project/trunk/config
在此結構中，samhoice的svn存儲庫中不存在osscomponent目錄。它由您的設置腳本添加爲OSS項目的工作目錄根。config目錄沒有從OSS項目簽出，並且在那裏不存在。 config目錄是由您的安裝腳本創建的，並從您的項目存儲庫中檢出config目錄。
所以在這個目錄結構中，你有三個結帳。沒有遞歸重疊，所以在任何子目錄上的svn映射之間沒有衝突。
如果您需要將您的配置文件安排在OSS項目的結構中，請在makefile或config腳本中添加一些符號鏈接。你也可以在你的svn客戶端的post-checkout鉤子裏做這個。
我在我的一個項目中使用了這樣的結構，用於在兩個項目樹之間共享一些代碼。共享的東西是在我爲你的配置部分推薦的子樹中。
我會檢查所有的代碼，因爲即使你不想改變他們還是沒有看到一個原因，現在，別人可能會看到後面的一個原因。此外，有可能是一個錯誤，或者簡單的重構，以提高可維護性和性能等。
爲SVN的基本佈局是：
branches/
tags/
trunk/
與一般的目錄結構（這三個下面）應當然與您的應用程序相匹配，以便您可以檢查出來並立即運行。你可以通過構建文件等做些微的修改。但我想結帳並去總是很好。有關更多信息或最佳實踐指南，我會使用您的技術查看其他開源項目。
至於配置文件 - 我不檢查那些不過，大多數項目在foo-dist文件，顯示該用戶的所有配置選項檢查。至少，他們需要將foo-dist複製到foo以啓用默認配置。
此外，你看過Google Code,Sourceforge或github項目託管包括版本控制？所有這三個提供您一噸，爲自由 - 也是免費的，你並不需要照顧的服務器爲您的項目託管等方面..
我用幾種方法，根據大小，和定製的第三方項目的數量：
對於小型或高度定製項目我會檢查整個事情，從股票代碼開始。這使得在整個項目中工作變得容易，並提供「一站式購物」來檢查構建它所需的一切。
對於大型或稍定製項目我會保持股票檔案（通常是.tar.bz2或.zip文件）的副本，並確保它的備份。然後，我將以某種形式將包含我的自定義設置的文件保存在版本控制之下。這裏的選項是
檢入（僅）自定義文件。如果您要修改源代碼，這通常是最好的選擇。
簽入用於自定義的腳本。如果腳本將輸入提供給配置實用程序，這是最有效的，因爲您將自定義設置（輸入數據）與庫存塊（配置實用程序）分開存儲。如果發佈新版本的第三方庫，通常很容易將自定義應用於其中，從而實現關鍵升級。
的項目是「永遠不會改變™，」或者哪些客戶有合約約束你特定版本，商店的股票代碼的某個地方，和版本控制下創建的補丁文件。然後，您可以通過修補程序發佈「已批准」版本。 注意：這是一個相當可怕的選擇，因爲補丁文件很難維護 - 如果您創建一個新補丁，您必須重新創建補丁文件或創建應用於第一個補丁之上的附加補丁。由於技術原因，選擇此選項的原因通常不會選擇。
我不能強調不夠，_you需要記錄建立這類項目並添加自定義的全過程，或自動，或（最好）兩種。很容易忘記哪些文件屬於哪裏或哪些文件屬於哪個文件，而且重新開始很痛苦。特別是如果你是繼承人。
祝你好運！
問題提出者特別希望他的配置文件在svn。 – Mnebuerquo 2008-10-30 14:03:32