Seb*_*ski 9 mercurial branch dvcs mercurial-queue
我已经和Mercurial合作了一段时间了.在对某些第三方软件进行(私有)更改时,我总是为这些更改创建一个单独的命名分支.当上游代码更新时,我只需将其合并到我的命名分支中.
今天,我读MQ(水银队列-章节12和13).我想我理解MQ背后的概念,所以我的问题是:
Mercurial中的MQ(命名)分支是否有任何优势(对于我的场景)？
Mar*_*ler 13
MQ优于命名分支的主要优点是:
您可以修改补丁.这使您可以编辑历史记录,因此您可以在上游代码之上维护一组干净且逻辑合理的补丁:如果您发现修补程序中存在错误,则刷新补丁而不是进行新的提交.
补丁中的更改将与上游所做的更改完全分开.合并两个分支时,将两个开发流混合在一起.这使得很难看到您所做的更改,而不会看到来自上游分支的更改.
补丁名称是暂时的.当您hg qfinish应用补丁时,提交中不会留下补丁名称的痕迹.因此,您可以在不首先与上游存储库协调的情况下使用MQ,因为它们永远不会注意到MQ.
你避免合并.相反,从上游最新的代码合并,你衍合你的应用的修补程序.这为您提供了更简单的历史记录.历史显然是假的,因为你假装在看到上游的代码之后你制作了所有的补丁- 实际上你是与上游并行完成的,然后将你的补丁移到了上游的顶端.
您在更改集中没有永久分支名称.人们有时会将命名分支视为一次性的,当他们意识到在历史中修复了命名分支时会感到不安.(实际上你可以hg branch在推送补丁之前设置分支名称,所以这一点并不是那么糟糕.)
MQ的缺点是:
这是一个额外的学习工具.它很强大,但它也为你提供了更多机会射击自己.运行hg qdelete将真正删除补丁,因此您可以丢弃数据.(我认为这很好,但我们有一个Git用户来我们的邮件列表抱怨这个.)
你使与他人合作变得更加困难.您可以变成.hg/patches存储库并在存储库之间推送/拉动补丁,但如果您不仅仅是一个开发人员,那么很难做到这一点.问题是如果多个人刷新同一个补丁,你最终会合并补丁.
您在更改集中没有永久分支名称.如果您正确使用命名分支并使用稳定的长期分支名称,那么在使用MQ时您将会错过.
| 归档时间： |
|
| 查看次数： |
1424 次 |
| 最近记录： |