我正在努力寻找适合我们工作方式的反复无常的工作流程。
我目前支持每个功能的克隆，但这是从 Subversion 转变的思维方式的一个很大变化。我们在设置环境时的当前费用也会有问题。
使用 hg pull --rebase 似乎为我们提供了更多类似 Subversion 的工作流程，但从阅读中我对使用它持谨慎态度。
我想我理解这些概念，并且我可以看到重写历史并不理想，但我似乎无法提出任何我个人认为不可接受的方案。
我想知道 hg pull --rebase 可以从理论上或从经验中创建的“最坏”场景是什么。我想要具体的例子，而不是关于你是否“应该”重写历史的观点。并不是说我反对有意见的人，只是似乎已经有很多人在互联网上表达了他们没有很多例子来支持他们；）
新的 Mercurial 转换者需要学习的第一件事是习惯于提交不完整的代码。Subversion 告诉我们你不应该提交损坏的代码。现在是时候忘掉这个习惯了。经常提交可以为您的工作流程提供更多的灵活性。
我看到的主要问题hg pull --rebase是能够在没有任何撤消方式的情况下中断合并。DVCS 模型基于显式跟踪历史的想法，并且 rebase 颠覆了这个想法，即我的所有更改都发生在您的所有更改之后，即使我们实际上同时在处理它们。而且因为我不知道您的更改是什么（因为我的代码基于早期的更改集），所以我很难知道我的代码在您的代码之上不会破坏某些东西。您还通过变基失去了分支功能，这实际上是 DVCS 背后的全部想法。
我们的工作流程（我们已经围绕它构建了一个完整的 Mercurial 托管系统）基于保留多个克隆或分支存储库，正如我们所说的那样。每个开发人员或小型团队都有自己的分支存储库，它只是“中央”存储库的克隆。我所有的新功能和大型错误修复都进入了我的个人分支存储库。我可以对代码进行同行评审，一旦它被认为准备好了，我就可以将它合并到中央存储库中。
这给了我一些不错的好处。首先，我不会破坏构建，因为我所有的更改都在他们自己的仓库中，直到它们“准备好”。其次，如果我需要做一个单独的功能，或者如果我有一些运行时间更长的东西，比如下一个主要版本，我可以创建另一个分支 repo。第三，如果有需要快速修复的错误，我可以轻松地更改中央存储库。
也就是说，您可以通过几种不同的方式使用此工作流程。最简单的，也是我开始使用的，只是保留单独的克隆。所以我将拥有website-central,website-tghw等。它运作良好，特别是因为您可以在本地推动和拉动它们。最近，我开始在同一个 repo 中保存多个 head，使用remotebranches扩展来帮助管理它们，并使用hg nudge来避免一次推送所有内容。
当然，有些人不太喜欢这种工作流程，通常是因为他们的 Mercurial 服务器很难进行服务器端克隆。在这种情况下，您还可以考虑使用命名分支来帮助保持您的功能直截了当。不幸的是，它们不像 Git 分支那样灵活（这就是我们更喜欢分支 repos 的原因），但是一旦你了解了如何关闭分支，以及为什么一旦启动一个分支就无法真正摆脱它们，它们就会很好地工作。
这有点长，所以我将通过鼓励您接受 Mercurial 提供的高级分支和合并来结束它（通过 SVN）。肯定有一个学习曲线，但是一旦你掌握了它，它确实会让事情变得更容易。
从问题评论中，您的根本问题是您的开发人员同时处理多个功能/错误修复/问题，并且在他们的工作目录中有未提交的工作以及一些准备好推回中央存储库的已完成工作。
有一个非常好的交流，很好地涵盖了这个问题，并导致了许多前进的方向。
http://thread.gmane.org/gmane.comp.version-control.mercurial.general/19704
有一些方法可以避免保留未提交的更改，例如通过单独的克隆来处理合并，但我的建议是采用分布式工作方式并尽可能多地提交 - 如果你真的觉得有必要，你可以在推送之前将最后几个本地提交合并到一个单一的变更集（例如使用 MQ）中。