是否允許在Mercurial中標記標籤？

Question

要更新我們的軟件的版本號，腳本執行以下操作：

$ hg update v3.3 
(sed+awk magic to edit version numbers in code base) 
$ hg commit -m"Create v3.3.50" 
$ hg tag v3.3.50 
$ hg push  
abort: push creates new remote head 101b0ff402c6 on branch 'v3.3'! 
(pull and merge or see "hg help push" for details about pushing new heads) 
$ hg pull --branch v3.3 --rebase 
... 
adding file changes 
added 1 changesets with 1 changes to 1 files (+1 heads) 
$ hg push 
... 
added 2 changesets with 4 changes to 4 files 

但提交後，標籤似乎沒有目標資源庫中存在：

$ hg tags | grep v3.3.50 
$ 

混淆，標籤是在.hgtags文件：

$ grep v3.3.50 .hgtags 
e7d6c19f8dd86cdad4cb41f543d09dbe5d30405e v3.3.50 

，並在修訂歷史：

$ hg log -b v3.3 
changeset: 7067:701358ca0f4b 
branch:  v3.3 
user:  Joe User <juser@example.com> 
date:  Wed Nov 11 12:41:15 2015 -0800 
summary:  Added tag v3.3.50 for changeset e7d6c19f8dd8 

changeset: 7066:19aafdd33263 
branch:  v3.3 
user:  Joe User <juser@example.com> 
date:  Wed Nov 11 12:41:15 2015 -0800 
summary:  Create v3.3.50 

hg commit/tag/push序列按預期工作，但添加rebase似乎至少部分刪除標記。標籤是否需要對rebase命令進行特殊處理？

Mercurial版本是2.9.2，系統正在運行最新版本的Ubuntu。

Answer 1

這是一個疏忽或故意的設計，很難說出它是什麼（更多關於下面的內容）。

您可以通過更新到分支的頭部，並通過重新標記修復：

hg tag -f -r REVID TAGNAME 

如果能夠更改或刪除標籤是intended design，所以這不是什麼稀奇古怪的。儘管如此，原始的標籤提交仍然存在。

如果你想明確這個是一個標籤更新，請使用

hg tag -f -e -r REVID TAGNAME 

，它允許你編輯標籤提交消息說，這是原始標籤的更新。

如果你已經安裝了進化，可避免查找原始版本，並使用：

hg tag --hidden -f -r 'successors(TAGNAME)' TAGNAME 

這裏，successors(...) revset功能描述最初的修訂標記爲TAGNAME已經演變成修訂。

如果您已經發展或使用hg histedit（並且您的重新標記的歷史記錄不包含自標記以來的合併），您也可以（原則上）更改原始標記提交，儘管我會建議您反對它有點挑剔（你基本上必須手動編輯.hgtags並更新提交消息）。

如果你想做到這一點，與演變做到這一點，最簡單的方法是：

hg update --hidden -r 'successors(TAGNAME)' 
edit .hgtags         # update tag information 
hg commit --amend       # update commit message 
hg evolve -a         # propagate changes 

這是histedit有點複雜：

hg histedit -r REVID       # REVID = tag commit 
# In the histedit editor, change "pick" to "edit" for the tag commit, 
# then write the file and leave the editor. 
edit .hgtags         # update tag information 
hg commit         # provide new commit message 
hg histedit --continue      # rebuild rest of history 

這兩種方法都依賴於這樣的事實該hg tag根本正常犯該塗改.hgtags和自動生成提交消息。水銀將只能依靠信息.hgtags和不檢查任何元數據。我也建議使庫的本地克隆提前，以防萬一你犯了一個錯誤，不知道如何從中恢復。

同樣，我不認爲這是必要的（甚至是一個好主意），但決定最終是你的。

---

所以，這是一個錯誤或設計？與重訂時自動移動標籤的一個問題是，原來的版本經常熬夜左右（hg rebase --keep或只是簡單的用會演變基），在這種情況下，目前尚不清楚是否要移動的標籤或沒有。它也不能解決與hg graft類似的問題。所以，它可能是。

Answer 2

.hgtags文件中的標記由變更集哈希標識標識。重新設置變更集會改變哈希值，因爲在計算哈希值時會包含關於其父項的數據。

在您的示例輸出中，「Create v3.3.50」更改集的散列值爲「19aafdd33263」 - 這與標記文件和標記更改集中引用的e7d6c19f8dd8不同。

但請注意，您可以重新綁定添加標籤的變更集，因爲標籤變更集哈希不會更改。

Answer 3

我們最近也遇到過這個問題，並試圖爲它提供複雜的解決方案，包括歷史操作和更新提交消息等等。最後，我們意識到，這是錯誤的重訂的unpushed變更，因爲我們那麼移動被指向出庫的一個獨特的快照複製到新的快照，這是不一樣的東西，因爲什麼是重訂完成，所以我們結束了下面的規則，並相應地改變了我們的腳本：

決不標記的unpushed變更

即在我們構建腳本我們現在pull，測試，增量版本，commit，pull --rebase如果需要的話，push記住散列，然後tag是哈希，commit，pull --rebase再次如果需要的話（現在沒有什麼可以再損壞）最後push對「.hgtags」做了修改。

我開了一個功能請求水銀，以便以更好的方式解決這個問題： https://bz.mercurial-scm.org/show_bug.cgi?id=5352