使用Mercurial，有没有办法快速备份到tmp存储库？
使用Macbook，我担心如果硬盘在路上坏了，那么3天的代码可能会全部丢失。
所以我实际上在我们的主服务器计算机上有一个 tmp 存储库，我可以hg push到它。困境是，除非我先提交，否则我不能推送，并且从以前的经验来看，除非我们准备好推送到中央服务器（与同事共享代码、合并等），否则我们不应该提交（原因是，我们无法推送选定的文件 - 我们必须推送所有已提交的文件或不推送任何内容）。那么如何解决这个问题呢？
有没有办法说“将所有修改的文件（和添加的文件）复制到中央服务器上的/user/peter/2010-06-18？）”或者不提交但以某种方式将其放到服务器上？
Using a Macbook, I am worried that if the hard drive is on the road and it goes bad, then 3 days of code can all be lost.
So I actually have a tmp repository on our main server computer, and I can hg push to it. The dilemma is, I can't push unless I commit first, and from previous experience, we shouldn't commit unless we are ready to push to a central server (to share code with coworkers, merge, etc) (the reason is, we can't push selected files -- we have to push all committed files or push nothing). So how to solve this?
Is there a way to say, "copy all MODIFIED FILES (and added files) to /user/peter/2010-06-18 on the central server?)" or not commit but somehow get it onto the server?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
正常的方法是提交。 DVCS 敦促人们“尽早承诺，经常承诺”。经常在本地提交，然后出于备份目的经常推送到服务器上的临时存储库。当您对工作感到满意时，您可以从临时存储库推送到共享的“中央”服务器。
无需确保在每个变更集之后所有内容都进行编译，规范是确保您推送的每个变更集后面都使“提示”处于可编译状态。一般情况下，每组变更集（changegroup）到达后都会触发持续集成构建服务器进行构建，并且只考虑“tip”。
如果你真的、真的无法忍受无法独立存在的变更集，那么善变的专业人士会使用 mercurial 队列，用于在处理补丁时将版本化补丁推送到单独的队列存储库。愿意玩火的人会在推送到共享存储库之前使用折叠扩展将变更集序列合并为单个变更集。
提供的三个选项中：
我认为第一个是最常见的，而且通常是“正确”的方式。
The normal way is to just commit. With a DVCS one is urged to "commit early, commit often". Commit locally often, then for backup purposes push to your tmp repo on the server frequently. When you're happy with your work, then you push from your tmp repo to your shared "central" server.
There's no need to make sure everything compiles after each changeset, the norm is to just make sure that each back of changesets you push leaves the 'tip' in a compileable state. Generally one triggers the continuous integration build server to turn a builds after each group of changesets (changegroup) arrives, and it only considers the 'tip'.
If you really, really can't stand having changesets that can't stand on their own, then a mercurial pro would use mercurial queues to keep a versioned patch pushed to a separate queue repository while working on it. Someone willing to play with fire would use the collapse extension to merge the sequence of changesets into a single changeset before pushing to the shared repos.
Of the three options presented:
I think the first is most commonly done, and generally the "right" way.