我对Mercurial相对较新,我的团队现在正在尝试将其作为Subversion的替代品.
如何将单个文件提交并推送到另一个存储库,同时保留我的工作目录中的其他修改未提交(或者至少不推送到其他存储库)？
这种情况发生在我们的数据库迁移中.我们希望将迁移提交到源代码控制,以便DBA可以在我们处理代码修改时查看和编辑它,以便与数据库迁移一起进行.这些变化还没有准备好,所以我们不想把它们全部推出去.
在颠覆中,我只是这样做:
svn add my_migration.sql # commit only the migration, but not the other files I'm working on svn commit -m "migration notes" my_mygration.sql
并继续在当地工作.
这不适用于mercurial,因为当我将它推送到另一个存储库时,如果我没有删除它的更改,它希望我将它们拉下来,合并它们并将该合并提交到存储库.合并后提交不允许您省略文件,因此它会强制您提交本地存储库中的所有内容.
我能想到的最简单的事情是将文件提交到我的本地存储库,克隆我的本地存储库,从实际存储库中获取任何新的更改,合并它们并提交该合并,然后它们将我的更改推送出去.
hg add my_migration.sql hg commit -m "migration notes" my_migration.sql cd .. hg clone project project-clone cd project-clone hg fetch http://hg/project hg push http://hg/project
这样可行,但感觉我错过了一些更简单的东西,某种方式告诉mercurial忽略我工作目录中已有的文件,只需进行合并并发送文件.我怀疑mercurial队列可以做到这一点,但我还没有完全搞定mq.
我最初提出这个问题差不多2年了.我现在做的不同(正如我在上面的问题上面的评论中提到的那样).我现在要做的是将我的更改提交到我的本地仓库中的一个文件(您可以使用hg记录扩展来仅提交文件的片段):
hg commit -m "commit message" filename
然后就推开.
hg push
如果存在冲突,因为已经对我需要首先合并的仓库进行了其他更改,我会更新到父版本(如果您不知道它是什么,请参见"hg parents -r."),commit我的其他变化,所以我有两个脑袋.然后恢复到原始单个文件提交并将更改拉/合并到该版本中.然后推出更改
hg push --rev .
仅推出单个文件和该修订的合并.然后你可以合并你在当地拥有的两个头.
这种方式摆脱了mq的东西和被拒绝的帅哥的潜力,并保持一切由源控制跟踪.如果您以后决定不需要它们,也可以"关闭"修订版.
有一个Mercurial功能可以实现搁置和取消搁置的命令,它们为您提供了一种交互式方式来指定要存储的更改,直到稍后:搁置.
然后你就可以hg shelve和hg unshelve暂时存放的变化了.它允许您在"修补程序"级别工作,以挑选和选择要搁置的项目.它似乎没有搁置一个已经列出要添加的文件,只有已经在repo中修改过的文件.
它包含在Mercurial中作为"扩展",这意味着您必须在hg配置文件中启用它.
真正旧版Mercurial的注释(包括搁置之前 - 不再需要):
我没有看到任何伟大的安装说明与一些谷歌搜索,所以这是我用来使其工作的组合的东西:
得到它:
hg clone http://freehg.org/u/tksoh/hgshelve/ hgshelve
项目中唯一的(当前)文件是hgshelve.py文件.
修改你的〜/ .hgrc以添加shelve扩展,指向你克隆repo的位置:
[extensions] hgshelve=/Users/ted/Documents/workspace/hgshelve/hgshelve.py
tl; dr:我原来的解释看起来很复杂,但我希望它能完全解释如何使用补丁队列.这是简短的版本:
$ hg qnew -m "migration notes" -f migration my_migration.sql $ hg qnew -f working-code # make some changes to your code $ hg qrefresh # update the patch with the changes you just made $ hg qfinish -a # turn all the applied patches into normal hg commits
Mercurial Queues使这类事情变得轻而易举,它使变更集的操作变得更加复杂.值得学习.
在这种情况下,首先您可能希望在下拉更改之前保存当前目录中的内容:
# create a patch called migration containing your migration $ hg qnew -m "migration notes" -f migration.patch my_migration.sql $ hg qseries -v # the current state of the patch queue, A means applied 0 A migration.patch $ hg qnew -f working-code.patch # put the rest of the code in a patch $ hg qseries -v 0 A migration.patch 1 A working-code.patch
现在让我们对工作代码做一些额外的工作.我将继续做qseries只是为了明确,但是一旦你建立了补丁队列的心智模型,你就不必继续查看列表了.
$ hg qtop # show the patch we're currently editing working-code.patch $ ...hack, hack, hack... $ hg diff # show the changes that have not been incorporated into the patch blah, blah $ hg qrefresh # update the patch with the changes you just made $ hg qdiff # show the top patch's diff
由于您的所有工作现在都已保存在修补程序队列中,因此您可以在应用远程更改后取消应用这些更改并将其还原.通常要取消应用所有补丁,只需这样做hg qpop -a.只是为了显示补丁队列的效果,我将一次一个地弹出它们.
$ hg qpop # unapply the top patch, U means unapplied $ hg qseries -v 0 A migration.patch 1 U working-code.patch $ hg qtop migration.patch $ hg qpop $ hg qseries -v 0 U migration.patch 1 U working-code.patch
此时,就好像您的目录中没有任何更改.做吧hg fetch.现在,您可以重新启动修补程序队列更改,并在存在任何冲突时合并它们.这在概念上有点类似于git的rebase.
$ hg qpush # put the first patch back on $ hg qseries -v 0 A migration.patch 1 U working-code.patch $ hg qfinish -a # turn all the applied patches into normal hg commits $ hg qseries -v 0 U working-code.patch $ hg out migration.patch commit info... blah, blah $ hg push # push out your changes
此时,您已经推出了迁移,同时保留了其他本地更改.您的其他更改位于队列中的修补程序中.我使用补丁队列进行大部分个人开发,以帮助我更好地构建我的更改.如果你想摆脱补丁队列并回到正常的样式,你必须导出你的更改并在"正常"的mercurial中重新导入它们.
$ hg qpush $ hg qseries -v 0 A working-code.patch $ hg export qtip > temp.diff $ rm -r .hg/patches # get rid of mq from the repository entirely $ hg import --no-commit temp.diff # apply the changes to the working directory $ rm temp.diff
我非常沉迷于补丁队列的开发,并且mq是最好的实现之一.同时进行多项更改的能力确实可以改善您的提交的重点和清洁程度.需要一段时间才能习惯,但它在DVCS工作流程中表现非常出色.
京公网安备 11010802040832号 | 京ICP备19059560号-6 