如何备份本地Mercurial存储库并使用rebase？
我的公司正在从 Subversion 迁移到 Mercurial。原因之一是我们希望能够通过 Hg 更加独立地工作。
我们期待使用变基作为从主存储库进行更新的主要方式（至少在开始时如此），以将历史记录保留在一行中，从而使从 Subversion 的过渡变得更容易。
现在，如果我们需要独立工作，我们有两个选择：在 Subversion 中创建一个分支，并在那里提交（又名合并地狱），或者根本不提交。借助 Mercurial，我们希望能够继续在本地进行承诺，并经常重新建立基础，从而获得独立性，同时避免创建命名分支的管理成本。
在备份出现之前，这一切听起来都很酷。对于 Subversion，很明显，如果有人不承诺，他们的工作可能会丢失。但不提交很快就会变得不方便（没有历史记录，没有日志消息等），所以人们还是会一次又一次地提交。
有了 Mercurial，就可以继续提交和重新调整基础，而无需花费很长的时间，从而使更多的工作面临风险。那么问题来了：如何备份开发者机器上的东西？
- 一种解决方案是使用一些外部备份软件，但这听起来不是一个好主意。
- 我们也可以一直推送到主存储库（甚至可能自动？），但这将导致无法使用变基，并且会导致主存储库中出现大量悬空的头。
- 我们可以推送到一个备份存储库，并尝试在主存储库中只有一个头。这听起来很复杂。
还有其他方法可以做到这一点吗？我希望找到一个解决方案，让我们的开发人员能够在一开始就使用他们的大部分 Subversion 知识。
My company is moving from Subversion to Mercurial. One of the reasons is with Hg we hope to be able to work more independently.
We are looking forward to using rebasing as our primary way to update from the main repository, at least in the beginning, to keep the history in one line, making the transition from Subversion easier.
Right now, if we need to work independently, we have two options: create a branch in Subversion, and commit there (aka merge hell), or not commit at all. With Mercurial we hope to be able to keep committing locally, and rebase every so often, thus gaining independence while staying free of the administration costs of bcreating named branches.
This all sounds cool until backing up comes into the picture. With Subversion it was obvious that if someone didn't commit, their work ccould be lost. But not committing became inconvenient quickly (no history, no log messages etc.), so people would commit time and again nevertheless.
With Mercurial it is going to be possible to go on committing and rebasing without pushing for extended periods of time, putting much more work at risk. So a question comes up: how to back up the stuff on developers' machines?
- One solution would be to use some external backup software, but that doesn't sound like a very good idea.
- We could also push to the main repo all the time (maybe even automatically?), but this would make it impossible to use rebasing, and would result in a lot of dangling heads in main.
- We could push to a backup repo, and try to have only one head in the main repo. This sound a lot complicated.
Are there any other ways to do this? I'd like to find a solution that would let our developers use most of their Subversion knowledge in the beginning.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
只是想把这个扔出去：我认为你犯了一个错误。线性历史并不是什么大问题，拉取/合并是更正常的善变工作流程。拥抱非线性历史，将 rebase 留给特殊场合。
你说“使用 Mercurial，我们希望能够继续在本地进行提交，并经常进行 rebase，从而获得独立性，同时避免创建命名分支的管理成本。”，但在 Mercurial 中，我们使用未命名分支来实现这一点，所以有没有管理费用。
请参阅 http://stevelosh.com /blog/2009/08/a-guide-to-branching-in-mercurial/#branching-anonymously 解释自动创建的未命名分支将如何零麻烦地为您提供所需的内容。
我知道这听起来好得令人难以置信，但您的朋友可以使用
hg pull和hg merge和hg Push> 当他们完成后，无需任何人考虑分支名称，或者谁拥有什么克隆，或任何其他事情，您将拥有一个协调中心，并且工作互不相关。Just to throw this out there: I think you're making a mistake. A linear history isn't a big deal and pull/merge is the much more normal mercurial workflow. Embrace a non-linear history and leave rebase for special occasions.
You say "With Mercurial we hope to be able to keep committing locally, and rebase every so often, thus gaining independence while staying free of the administration costs of bcreating named branches.", but in mercurial one uses unnamed branches for this, so there's no administration costs.
See http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/#branching-anonymously for an explanation of how unnamed branches created automatically will give you exactly what you want with zero hassle.
I know it sounds like too-good-to-be-true snake oil, but your folks can just
hg pullandhg mergeandhg pushwhen they're through and without anyone having to think about branch names, or who has what clone, or anything, you'll have a coordinated center with disconnected work.您还可以为每个开发人员提供一个存储库：
他们可以在其中推送他们想要的一切。
这意味着有很多悬而未决的头，但这可能没问题，因为在恢复之前没有人会看它们……然后你只需询问当前提示的祖先：
如果我使用这个方案，我' d 设置：
在
.hgrc/hgrc中。或者，您可以通过在其全局
~/.hgrc中进行设置，为每个开发人员提供一个整体备份存储库：You could also give each developer a repo:
Where they can push to all they want.
It would mean a lot of dangling heads, but that's probably OK because nobody would look at them until it comes time to restore… Then you'd simply ask for only the ancestors of the current tip:
If I were using this scheme, I'd set:
in
.hgrc/hgrc.Alternatively, you could give each dev one overall backup repo by setting this in their global
~/.hgrc:我认为你的做法是错误的。
您所描述的看起来更像是您试图建立一个工具来确保/执行流程，而不是支持流程。
与集中式方法相比，以分散式方式工作是一个相当大的转变，并且通过尝试施加您所描述的那种约束，很可能会对开发人员所感受到的体验造成更多的伤害而不是好处。
如果您担心他们不会定期将更改推送到主存储库，那么最好问问自己（也问他们）“我们准备好改变我们的流程了吗？< /em>”
许多人仍然声称 DVCS 会给他们的软件工厂带来混乱。确实，DVCS 并不强制执行线性（单点故障）工作方式，但带来混乱的不是工具，而是您在公司中建立的团队精神。
现在，如果您必须迁移到 Mercurial（因为它已经出售给管理层，或者其他什么），但对 SVN 方法感觉更舒服，再加上一点“附加”，请尝试使用HgSubversion。以后迁移仍然会很容易。
I think you're doing it the wrong way.
What you describe looks more like you're trying to put in place a tool to ensure/enforce a process, rather than to support the process.
Working in a decentralized way is quite a big shift compare to the centralized approach, and by trying to put the kind constraint you describe will more than likely cause more hurt than good for the experience perceived by your developers.
If you're scared that they won't push their changes on a regular basis to a main repository, then it would be good to ask yourself (and to ask them too) "Are we ready to change our process?"
Many people still claims that the DVCS will bring chaos to their software factory. It's true that the DVCS'es don't enforce a linear (single-point-of-failure) way to work, but what bring chaos is not the tool, it is the team spirit you built in your company.
Now, if you HAVE TO migrate to Mercurial (because it's already sold to the management level, or whatever), but feels more comfortable with the SVN approach, with a little "plus", try using HgSubversion first. Migration will still be easy later.