您想在回購協議中保留詳細的歷史記錄,但您希望擁有(並能夠導出)僅包含「合理」回報的理想歷史記錄,對嗎?我可以同情。
解決方案1:使用標記標記歷史中有趣的點,並學會忽略它們之間的所有雜亂的位。
解決方案2:使用兩個分支併合並。在分支default
中進行開發,並保持並行分支release
。 (你可以稱它爲clean
,但實際上你正在管理版本)。每當default
處於穩定狀態時您想要檢查點,切換到分支release
和合併到到它的當前狀態default
- 批量,如果您願意。如果您從未直接向release
提交任何內容,則永不會發生合併衝突。
(original branch) --o--o--o--o--o--o--o (default)
\ \ \
r ... ... --r--------r (release)
結果:您可以更新到release
任何修訂,並期望一個正常運作的狀態。你可以運行hg log -r release
,你只會看到選定的檢查點。你可以檢查完整的日誌,看看事情是如何發生的。缺點:因爲release
分支取決於default
,所以如果不帶上default
就不能將其推送到其他回購站。由於重複的合併,hg glog -r release
也會顯得很奇怪。
解決方案3:使用如上所述的命名分支,但使用rebase
擴展名而不是合併。它可以選擇複製而不是直接移動重新發布的變更集;它有一個選項--collapse
,可以將一組修訂轉換爲一個修訂。只要你有一組修訂版r1:tip
要終結,從default
複製他們release
如下:
hg rebase --source r1 --dest release --keep --collapse
這推動在release
頭一個版本,即相當於從R1到整個變更default
的負責人。 --keep
選項使其成爲副本,而不是破壞性重寫。優點是release
分支看起來就像你想要的那樣:漂亮乾淨,你可以在不拖動默認分支的情況下推送它。缺點是你不能把它的階段與default
中的修改聯繫起來,所以我會推薦方法2,除非你真的有來隱藏中間修訂。 (另外:分批擠壓你的歷史並不容易,因爲rebase會移動/複製「源」版本的所有後代)。
所有這些都需要你做一些額外的工作。這是不可避免的,因爲mercurial沒有辦法知道你想擠壓哪個版本。
@ Ry4an - 這是您在相關問題中提出的建議保留歷史記錄的評論,所以如果您想回答的話,我正在給您發送警報。 – psr
我不認爲你可以ping你還沒有發佈的人。 – Laf
爲什麼你想在保存時自動提交?不會導致非編譯提交?如果是這樣的話,那麼如果你有這個需求,那麼'hg bisect'很難使用。 –