在SVN中，我們有一個使用休眠等所有數據庫邏輯的項目。但是，該項目依賴於處於特定狀態的數據庫模式匹配代碼。正在尋找在Subversion項目結構中正確處理配置和數據庫模式文件
同樣，我們還將在配置目錄中配置用於運行服務器的腳本。
如何正確設置SVN中的項目結構來克服這個問題？
的結構可能是這樣的：
--DBHibernateProject
------trunk
------branches
------tags
--DatabaseScriptsProject
------trunk
------branches
------tags
--ConfigProject
------trunk
------branches
------tags
但是，我們如何配合數據庫腳本項目說發佈 - 1.0 DBHibernateProject的？ hibernate項目在maven倉庫中有一個可部署的資產（jar），但是db腳本沒有。我想確保正確的數據庫腳本與正確的應用程序版本綁定。
您可以通過流程或製作一個SVN項目來完成。
你可以爲團隊制定一個規則，當你完成一組數據庫的東西時，你用一個與它所用代碼的標籤相同的標籤來標記它。這可能很乏味，但如果更改通常在數據庫和代碼之間同步，則可行。
另一種方式是在SVN中創建一個項目，並使用一箇中繼和一組標記和分支。然後你通過在回購的頂層有一些文件夾來完成同樣的事情，這些文件夾包含代碼，腳本和休眠的東西。有可能管理SVN倉庫的權限，以便不同的人對特定文件夾具有寫入權限，但是每創建一個分支時會產生一個花費，以便不斷修改權限（也許標記是否愚蠢地允許修改標籤）
我想過SVN中的單個項目，但似乎大多數人使用的項目少於多個項目。我們想要使用多個項目，因爲我們會有不相關的項目。另外一些使用數據庫的項目可能有自己的版本。 IE - ProjectA 1.0使用DBProject 1.0，但ProjectB 2.0使用DBProject 1.0。 – Oggie
我會強烈建議使用liquibase來管理數據庫遷移。這些更改文件是從類路徑中讀取的，這意味着它們可以與匹配的Hibernate類文件一起部署在同一個jar中。
我從來沒有使用它，但liquibase確實有一些支持hibernate這可能會證明是有用的。
對於Maven的例子中看到：
對於一些更加理論化的閱讀，我建議：
公平的利益也有在同一個功能空間其他一些工具：
如果「項目依賴於...「意思是說，」對於DBHibernateProject的每一個版本，我們必須使用DatabaseScriptsProject和ConfigProject的預定義和固定版本（它們在DBHibernateProject樹中使用/引用）「您始終可以使用純粹的Subversion端解決方案：帶PEG修訂版的外部版本
沒有有關源代碼樹的知識結構不能再多說了：「依賴」和「中也有配置腳本」是不可翻譯的（容易）到正規的依賴性，就像（我可憐的重建）
DBHibernateProject的每個修訂版必須有相關的 DatabaseScriptsProject（對於此代碼正確的模式）和 ConfigProject（爲腳本，製作數據庫架構，這是DBHibernateProject使用 ）
如果我的改造是正確的，在顛覆式的（沒有的Maven ，這可能是我的錯誤）我將在DBHibernateProject樹中創建兩個目錄類型外部引用，分別在DatabaseScriptsProject和ConfigProject樹中引用「某些狀態下的某個樹」
難道你沒有單個項目佈局數據庫項目看起來像這樣：
----DatabaseProject
-------trunk
--------DBHibernateProject
--------DatabaseScriptsProject
-------branches
-------tags
----OtherProject
-------trunk
-------branches
-------tags
----ConfigProject
-------trunk
-------branches
-------tags
如果配置項目沒有綁定到其他項目和服務器的腳本，那麼我的猜測是你可以把它作爲與OtherProject相同的佈局。
正如你已經提到你的標籤中的maven，你爲什麼不使用版本的依賴？ –
當實際上沒有資產（戰爭，jar等）時，如何使用腳本項目的依賴關係。它只是一個POM的依賴？ – Oggie