我正在努力寻找适合我们工作方式的多变工作流程。
我目前倾向于对每个功能进行克隆，但这与 Subversion 的思维方式相比发生了很大的变化。我们还会遇到当前设置环境的费用问题。
使用 hg pull --rebase 似乎给我们提供了更多类似 Subversion 的工作流程，但通过阅读周围的内容，我对使用它持谨慎态度。
我认为我理解这些概念，并且我可以看到重写历史并不理想，但我似乎无法想出任何我个人认为不可接受的场景。
我想知道 hg pull --rebase 可以在理论上或根据经验创建的“最糟糕”场景是什么。我想要具体的例子，而不是关于你是否“应该”重写历史的观点。并不是说我反对人们发表意见，只是似乎已经有很多意见在互联网上表达，但没有很多例子来支持它们；）
I'm struggling to find the mercurial workflow that fits the way that we work.
I'm currently favouring a clone per feature but that is quite a change in mindset moving from Subversion. We'll also have issues with the current expense we have in setting up environments.
Using hg pull --rebase seems to give us more of a Subversion-like workflow but from reading around I'm wary of using it.
I think I understand the concepts and I can see that rewriting the history is not ideal but I can't seem to come up with any scenarios which I personally would consider unacceptable.
I'd like to know what are the 'worst' scenarios that hg pull --rebase could create either theoretical or from experience. I'd like concrete examples rather than views on whether you 'should' rewrite history. Not that I'm against people having opinions, just that there already seem to be a lot of them expressed on the internet without many examples to back them up ;)
发布评论
评论（2）
新的 Mercurial 转换者需要学习的第一件事是适应提交不完整的代码。 Subversion 告诉我们，你不应该提交损坏的代码。现在是时候改掉这个习惯了。经常提交可以让您的工作流程更加灵活。
我认为 hg pull --rebase 的主要问题是能够在没有任何方式撤消的情况下中断合并。 DVCS 模型基于显式跟踪历史的想法，而变基则颠覆了该想法，即我的所有更改都在您的所有更改之后发生，即使我们实际上是同时处理它们的。而且因为我不知道您的更改是什么（因为我的代码基于早期的更改集），所以我更难知道我的代码在您的代码之上不会破坏某些内容。您还会因变基而失去分支功能，这实际上是 DVCS 背后的全部理念。
我们的工作流程（我们已经构建了整个 Mercurial 托管系统）基于保留多个克隆或分支存储库，正如我们所说的那样。每个开发人员或小团队都有自己的分支存储库，它只是“中央”存储库的克隆。我的所有新功能和大错误修复都会进入我的个人分支存储库。我可以对该代码进行同行评审，一旦认为准备就绪，我就可以将其合并到中央存储库中。
这给我带来了一些好处。首先，我不会破坏构建，因为我的所有更改都在它们自己的存储库中，直到它们“准备好”为止。其次，如果我需要执行单独的功能，或者如果我有一些运行时间较长的内容（例如下一个主要版本），我可以创建另一个分支存储库。第三，如果存在需要快速修复的错误，我可以轻松地对中央存储库进行更改。
也就是说，您可以通过多种不同的方式使用此工作流程。最简单的方法，也是我一开始的方法，就是保留单独的克隆。因此，我将拥有
website-central、website-tghw等。它运行良好，特别是因为您可以在本地在它们之间进行推送和拉取。最近，我开始使用 remotebranches 扩展在同一个存储库中保留多个头帮助管理它们并hg nudge不要同时推动所有事情。当然，有些人不太喜欢这个工作流程，通常是因为他们的 Mercurial 服务器很难进行服务器端克隆。在这种情况下，您还可以考虑使用命名分支来帮助保持功能的直线性。不幸的是，它们不像 Git 分支那么灵活（这就是为什么我们更喜欢分支存储库），但是一旦您了解如何关闭分支，以及为什么一旦启动分支就无法真正摆脱它们，它们就会很好地工作。
这有点长，所以我会鼓励您接受 Mercurial 提供的高级分支和合并（通过 SVN）来结束它。肯定有一个学习曲线，但是一旦你掌握了它，它确实会让事情变得更容易。
The first thing new Mercurial converts need to learn is to get comfortable committing incomplete code. Subversion taught us that you shouldn't commit broken code. Now it's time to unlearn that habit. Committing frequently gives you a lot more flexibility in your workflow.
The main problem I see with
hg pull --rebaseis the ability to break a merge without any way to undo. The DVCS model is based on the idea of tracking history explicitly, and rebasing subverts that idea by saying that all of my changes came after all of your changes, even though we were really working on them at the same time. And because I don't know what your changes are (because I was basing my code off of earlier changesets) it's harder for me to know that my code, on top of yours, won't break something. You also lose the branching capabilities by rebasing, which is really the whole idea behind DVCSs.Our workflow (which we've built an entire Mercurial hosting system around) is based on keeping multiple clones, or branch repositories, as we call them. Each dev or small team has their own branch repository, which is just a clone of the "central" repository. All of my new features and large bug fixes go into my personal branch repo. I can get that code peer reviewed, and once it's deemed ready, I can merge it into the central repo.
This gives me a few nice benefits. First, I won't be breaking the build, as all of my changes are in their own repo until they're "ready". Second, I can make another branch repo if I need to do a separate feature, or if I have something longer-running, like for the next major version. And third, I can easily get a change into the central repo if there's a bug that needs to be fixed quickly.
That said, there are a couple different ways you can use this workflow. The most simple, and the one I started with, is just keeping separate clones. So I'll have
website-central,website-tghw, etc. It works well, especially since you can push and pull between them locally. More recently, I've started keeping multiple heads in the same repo, using the remotebranches extension to help manage them and hg nudge to keep from pushing everything at once.Of course, some people don't like this workflow as much, usually because their Mercurial server makes it hard to make server-side clones. In that case, you can also look at using named branches to help keep your features straight. Unfortunately, they're not quite as flexible as Git branches (which is why we prefer branch repos) but they work well once you understand how to close branches, and why you can't really get rid of them once you start one.
This is getting a bit long, so I'll wrap it up by encouraging you to embrace the superior branching and merging that Mercurial provides (over SVN). There is definitely a learning curve, but once you get the hang of it, it really does make things easier.
从问题评论来看，您的根本问题是您的开发人员同时处理多个功能/错误修复/问题，并且在其工作目录中有未提交的工作以及一些已完成的工作，可以准备将其推回到中央存储库。
这是一次非常好的交流，很好地涵盖了这个问题，并提出了许多前进的方向。
http://thread.gmane.org/gmane.comp。 version-control.mercurial.general/19704
有多种方法可以避免保留未提交的更改，例如通过 一个单独的克隆来处理合并，但我的建议是拥抱分布式工作方式并根据需要经常提交 - 如果您确实觉得需要，您可以结合最后几个本地在推送之前提交到单个变更集（例如使用 MQ）。
From the question comments, your root issue is that you have developers working on several features/bug fixes/issues at one time and having uncommitted work in their working directory along with some completed work that is ready to be pushed back to the central repository.
There's a really nice exchange that covers the issue well and leads on to a number of ways forward.
http://thread.gmane.org/gmane.comp.version-control.mercurial.general/19704
There are ways you can get around keeping your uncommitted changes, e.g. by having a separate clone to handle merges, but my advice would be to embrace the distributed way of working and commit as often as you like - if you really feel the need you can combine the last few local commits into a single changeset (using MQ, for example) before pushing.