The patch management problem 补丁管理问题
Here is a common scenario: you need to install a software package from source, but you find a bug that you must fix in the source before you can start using the package. You make your changes,
forget about the package for a while, and a few months later you need to upgrade to a newer version of the package. If the newer version of the package still has the bug, you must extract your fix from the older source tree and apply it against the newer version.
This is a tedious task, and it's easy to make mistakes.
这是个常见的场景: 你需要安装一个软件包，但是你发现了一个需要在源代码中进行修改的bug。你做了修改，暂时忽略这个包一会儿，几个月后你需要把这个包升级到新的版本。如果新的版本仍有bug，你必须把你的修改从旧版本中取出来然后应用到新版本。这是一个冗长而乏味的任务，也容易犯错。
This is a simple case of the “patch management”
problem. You have an “upstream” source tree that you can't change; you need to make some local changes on top of
the upstream tree; and you'd like to be able to keep those changes separate, so that you can apply them to newer versions of the upstream source.
这是个简单的“补丁管理”问题的简单例子.
你有一块你不能更改的“上游”源代码;
你需要在这部分源代码上做一些本地修改;
你希望能够单独地保留这些更改,并将他们应用在“上游”源代码的新版本上。
The patch management problem arises in many situations. Probably the most visible is that a user of an open source software project will contribute a bug fix or new feature to the project's
maintainers in the form of a patch.
补丁管理问题在很多情况下会出现。最常见的是：一个开源软件项目的用户以一个补丁的方式给项目维护者提供一个bug补丁或者新特性。
Distributors of operating systems that include open source software often need to make changes to the packages they distribute so that they will build properly in their environments.
包含开源软件的操作系统分销商经常需要去给他们分销的包做些更改所以在他们的环境中很适合。
When you have few changes to maintain, it is easy to manage a single patch using the standard diff and patch programs
(see the section called “Understanding patches” for
a discussion of these tools). Once the number of changes grows, it starts to make sense to maintain patches as discrete “chunks of work,”
so that for example a single patch will contain only one bug fix (the patch might modify several files, but it's doing “only one thing”),
and you may have a number of such patches for different bugs you need fixed and local changes you require. In this situation, if you submit a bug fix patch to the upstream maintainers of a package and they include your fix in a subsequent release, you can
simply drop that single patch when you're updating to the newer release.
当你做一点变更，用标准的diff和patch程序很容易管理一个简单的补丁。一旦变更增多，维护补丁也就变得有意义啦，所以，举个例子，一个简单的补丁只包含一个bug修补(这个补丁可能会修改一些文件，但它做的是“一个任务”)，你可能有一些相对应不同bug的一些补丁，需要做些修改。这种情况下，如果你提交一个包补丁给上游的维护者，他们随后会把你的补丁包含进去，当你升级到新版本后你只需drop掉那个补丁。
Maintaining a single patch against an upstream tree is a little tedious and error-prone, but not difficult. However, the complexity of the problem grows rapidly as the number of patches
you have to maintain increases. With more than a tiny number of patches in hand, understanding which ones you have applied and maintaining them moves from messy to overwhelming.
在上游树上维护一个补丁有点繁琐也容易出错，但不是很空难。然而，问题的复杂性锁着你维护的补丁增多而加剧。有许多补丁需要着手处理时，理解你已经应用的补丁并将解决它们。
Fortunately, Mercurial includes a powerful extension, Mercurial Queues (or simply “MQ”),
that massively simplifies the patch management problem.
幸运的是，Mercurial有一个有力的扩展,Mercurial Queues(简称"MQ")，这大大地简化了补丁管理问题。