管理Mercurial版本中的流程工件

我想知道使用Mercurial創建包含工件的版本修訂版本的最佳方式，該工件提供了流程執行的證據。例如，我們希望附加系統測試結果，檢查列表，發佈說明等，以便如果我們由客戶審覈，我們可以輕鬆地顯示我們執行了我們的流程。由於我們產品的安全性，這對我們很重要。管理Mercurial版本中的流程工件

我們的發佈管理流程將如下圖所示。所有開發人員都在本地回購，並定期推向主流。對於開發團隊之外的內部工程目的，Main是最新且最好但不一定安全的。

當我們想爲客戶或其他內部工程部門創建一個版本時，我們從候選版本分支（例如RC1）開始。如果需要修復，我們會向RC分支提交。測試發生在這個分支上。當RC被確定爲良好時，這些更改將合併回主。

我們認爲我們想要做的就是合併到一個Releases分支中。然而，我們有一個雞與雞蛋相關的問題：我們希望包含在版本修訂版中的工件包含修訂版的哈希等。這提供了明確的可追溯性，即測試和其他處理步驟在此精確修訂版本上執行。但是，爲了添加這些項目，我需要創建一個新的修訂版，並且在創建修訂版之前，我顯然無法知道該修訂版的哈希值是什麼。我想知道是否有某種方法來修改修訂而不更改散列？

例如，我可以想到的唯一方法就是在下圖中創建一個RC2.3修訂版本，其中包含必要的流程工件但實際上將RC2.2合併到版本。

然後，當然，我還有一個問題，那就是將RC2.2合併到發行版中會生成一個新的散列。所以，我的神器再次過時了。所以接下來的問題是是否有某種方法讓Release分支「指向」RC2.2。

順便說一下，如有必要，我們願意改變這個過程。我們使用此方法的原因如下：

CI系統正在監控main並啓動一系列構建，並在每次推動時執行自動化單元測試。主要有頻繁的變化，我們不希望人們使用它。
開發可以繼續進行，對發佈沒有影響。
任何版本分支上的修訂都會在我們的CI平臺上啓動一系列不同的任務，包括創建現場刷新實用程序的分發和所需映像（我們正在開發固件）。這就是我們向外部實體提供發佈的方式。

Main   A--B--C--D--E--F--G--H--I--J--K--L---------M-------------N 
         \   /  \     / 
RC1      RC1.0--RC1.1   \     / 
         \      \    / 
RC2      \      RC2.0--RC2.1--RC2.2 
          \          \ 
          \          \ 
Releases     ER1.0-----------------------------------PR1.0

來源

2013-11-21 sje

要回答你的問題：

我想知道是否有某種方式來「修正」修訂不改變的哈希？

不，這是不可能的設計。變更集散列是從提交內容派生的加密校驗和 - 這就是變更集散列唯一標識變更集中所有文件內容的原因。

Mercurial wiki有一個standard branch setup的頁面。我將描述它如何與下面的圖片一起使用。

在你的情況下，人們通常會做的是爲你的建議創建一個發佈候選分支。如果您即將發佈固件版本2.0，那麼我會致電分支2.x。在樹枝上的提交是候選發佈版爲您的2.0版本：

Main  A--B--C--D--E--F--G--H--I--J--K--L---------M-------------N 
       \    /
2.x    2.0-RC1--2.0-RC2

修復的問題是在分支致力於根據需要，定期合併回主。您應該始終能夠將錯誤修正合併回來，因爲它們的性質錯誤修復和您想要在Main上修復的穩定性也是如此。換句話說，上面的提交I在2.0-RC2中加了錯誤修正，加上D到H中的新功能。

您可以在候選版本分支工作，就像你想，並保持固定的錯誤：

Main  A--B--C--D--E--F--G--H--I--J--K--L-------M-------------N 
       \   /    /
2.x    2.0-RC1--2.0RC2 -- ... --2.0-RC8

所有錯誤修正將會被合併，因爲規則是，你只能做修復的候選版本分支是安全的。在這裏，你在發佈分支上有8個候選版本。

當您喜歡發佈候選版本的狀態時，您可以對其進行標記並對您標記的修訂版運行更全面的測試。一個succesfull測試的輸出致力於在樹枝上，然後你標記是提交作爲最終發佈的版本：

Main  A--B--C--D--E--F--G--H--I--J--K--L-------M-----------N 
       \   /    /  /
2.x    2.0-RC1--2.0RC2 -- ... --2.0-RC8 -- T -- 2.0

這裏T有包括測試輸出2.0-RC8。提交T是您標記爲軟件2.0版本以及您打包併發送給客戶的軟件。

如果您需要創建一個版本2.1有bug修正至2.0（但沒有新的功能），那麼你就繼續使用相同的方案：

Main  A--B--C--D--E--F--G--H--I--J--K--L-------M-----------N 
       \   /    /  /
2.x    2.0-RC1--2.0RC2 -- ... --2.0-RC8 -- T -- 2.0 -- 2.1-RC1

這就是爲什麼我叫分支2.x。

來源

2013-11-22 10:59:42

你的善變的使用似乎有點複雜，與所有那些合併所有的地方，將是痛苦的處理。您正在使用的水銀分支機構功能，但似乎忽略了其他2個重要的特點：

標籤
挑櫻桃

我將在下面說明我們的水銀一般使用高亮這些特徵：

請注意，以下僅適用於需要隨時間維護不同版本的項目。

主分支（在mercurial中稱爲默認值）專用於您當前的應用程序開發。每次開發人員完成功能的開發/修改/更新時，他/她都會將其更改推送到默認值，然後每個人都可以使用，並且可以保證我們的CI（jenkins）不會中斷任何操作。

當我們到達一個新版本即將發佈的階段時，會創建一個分支。關於您的模式，可以將該分支命名爲MY_PRODUCT_1_0

開發人員將繼續在默認分支上工作，並且任何時候需要在即將發佈的版本中提交時，相關的更改集將通過以下方式複製到MY_PRODUCT_1_0分支：命令hg graft REV_CHANGESET（櫻桃選擇）（注意，您也可以從MY_PRODUCT_1_0分支複製到默認值）。

因此，您基本上選擇默認分支中的哪些變更集將使其達到當前版本，而不必合併2個分支。

這需要開發人員推動清潔和原子的變化集，這是mercurial首先應該如何完成的。

正如你犯MY_PRODUCT_1_0發展，你可將其標記沿途多次作爲你的模式從MY_PRODUCT_1_0_RC_1，MY_PRODUCT_1_0_RC_2，... 當最後的變更是在此分支的，你只需要添加標籤MY_PRODUCT_1_0_PR_1_0

然後，您最初只能獲得2個分支，默認（開發分支）和MY_PRODUCT_1_0（您的第一個版本），隨着時間的推移需要發佈新版本的產品時，您將創建一個新分支MY_PRODUCT_2_0並如上所述重新開始循環。

通過這種方法，您可以確保您只在發佈版中具有所需的更改，而不會在合併分支時獲得額外的更改。

我希望我很清楚，如果不讓我知道。

來源

2013-11-21 20:50:19 Farid

管理Mercurial版本中的流程工件

回答

相關問題