自動數據庫版本控制和Mercurial（也可能是git）

Question

我們已經使用了多年的顛覆，但現在正在轉向mercurial。

我們使用的TeamCity和腳本一個漂亮的自動化數據庫版本系統。 （它是.net和msbuild和powershell，但這是無關緊要的）。 ]

我們有一個數據庫目錄，例如：

/database/ 
/database/functions 
/database/migration 
/database/storedprocedures 
/database/views 

的migration文件夾中包含的東西DDL和數據修改。

源/編譯系統的工作原理是這樣：

1. 開發者進行了更改存儲過程
2. 開發者提交修改使用svn
3. TeamCity的簽出代碼，並建立
4. 數據庫遷移代腳本運行得到啓動構建版本的svn修訂版
5. 腳本在數據庫目錄中執行最後一次已知版本與此版本之間的差異。對於那些在差異中的所有文件，它連接它們與文件名的文件％buildnumber％_％版本％的.sql
6. 腳本把最後的「更新databaseinfo setversion =‘％buildnumber％’到FIEL
7. 腳本，然後提交新的文件回顛覆
8. 構建打包

然後在發佈時，或開發時間，它是物質的運行，以便瞧的SQL遷移文件，數據庫升級和遷移。

這是一個很好的系統，因爲這意味着你做了你的工作，不必擔心寫入遷移，或者注意到你的改變，沒有「對測試環境感到抱歉，我忘了寫存儲過程的遷移，等待30分鐘，我會給你一個新的版本「

但是，隨着移動到mercurial，步驟7. Script then commits this new file back into subversion不能正常工作。

顛覆它不是一個大問題，因爲你只是犯回，從來沒有被構建系統之外修改數據庫目錄。

隨着善變（我有點新手在這裏），我們需要提交和推送這需要做一個拉和更新的變化。我可以讓這個工作沒有問題，但是它的代價是將源代碼置於無效狀態，並且只是覺得這是錯誤的做法。

我正在考慮使用mercurial內部的提交/預提交鉤子，但是隨後我們失去了構建編號版本控制，並在尋找命名約定來爲該版本的數據庫版本尋找問題，然後再次運行時我們有一個分支。

我想知道其他人在這附近做些什麼？

Answer 1

這是值得的。我結束了這個與mercurial提交鉤。

因爲我們正在使用windows & powershell。

我把這個在hgrc

[hooks] 
commit.MigrateDatabase=powershell -File ".\BuildAndDeploy\DatabaseMigration_HgHook.ps1" 

而且在PowerShell中的文件，沿總而言之

$ hg_node切=（GCI -Path ENV：hg_node）.value的 $ hgCommandLine = 「汞狀態--change $ hg_node> \ Migration.Working \ ModifiedFiles.txt」 調用，表達$ hgCommandLIne

然後解析的ModifiedFiles.txt任何添加或修改的文件，它們級聯到另一個文件和VERS基於版本和編排日期的組合來對此進行分析。

Answer 2

如果您的自動變化是這樣的：

1. 拉和更新
2. 在一個目錄下創建一個新的文件
3. 提交新的文件到存儲庫
4. 推

那麼你在做什麼是時間上的，你會得到一個額外的頭。在你拉的時候，別人可能會推出一個新的頭（在舊頭上），你的本地存儲庫（在構建服務器上）不知道。

這就是所有這些都是錯誤的。如果你沒有修改現有的文件，那麼這裏就不會出現合併衝突，因爲你只是在現有的變更集之上提交，所以構建服務器根本就不會合並。

即。按時間順序，這將會發生什麼。這是當前的主要存儲庫時間表：

1---2---3---4---5 

您拉，並將其獲取到您的構建服務器。然後創建與修改一個新的文件，並提交，形成該時間表：

1---2---3---4---5---6 

與此同時，另一家開發商也推了新的變更到主存儲庫中，所以當你推，你會得到這樣的：

1---2---3---4---5---6 
       \ 
        \-7 

（6或7是您的新變更集，另一個來自其他開發者）。

這是最糟糕的情況。你可以嘗試在構建服務器上automerge。再次，這不應該產生合併衝突。