Mercurial：修复早期版本中的错误有什么好处
根据指南，在标题下：修复早期版本中的错误< /strong>，它指出：
当您在某些早期版本中发现错误时，您有两个选择：要么在当前代码中修复它，要么您可以返回历史记录并准确修复代码，这会创建更清晰的历史记录。
- 回顾历史如何让它变得更清晰？它仍然在提示处创建一个新的变更集。
- 它与记录为父项的内容有关吗？
- 有没有办法查看日志以按顺序查看新插入的变更集？
- 本课程的主要标题是具有非线性历史的孤独开发人员。在团队中工作时这是一个好的做法吗？
According to the guide, under the heading: Fixing errors in earlier revisions, it states this:
When you find a bug in some earlier revision you have two options: either you can fix it in the current code, or you can go back in history and fix the code exactly where you did it, which creates a cleaner history.
- How does going back in history make it cleaner? It still makes a new changeset at tip.
- Does it have something to do with what is recorded as it's parent?
- Is there a way to view the logs seeing the newly inserted changeset in that order?
- This lesson is under the main heading of Lone developer with nonlinear history. Is this good practice when working on a team?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
1）它通过提供更接近错误产生的修复来使其更清晰。因此，如果您在错误发生后有多个克隆，每个克隆都可以引入修复更改集，其中不包含与后续更改相关的任何代码。它确实创建了一个新的变更集（提示）。然后，您需要将该修复与所有相关的克隆合并。
2）是的。因为您正在克隆创建错误的代码，所以修订历史记录直接引用错误起源的变更集，因此它有助于记录（直接而不仅仅是通过注释）更改存在的原因。
3) 变更集永远不会出现插入状态 - 它必须始终在树中稍后合并，就像合并任何其他克隆一样。
4）我不认为这种方法与任何团队方法有什么不同。在任何一种情况下，您都需要与团队沟通以指示修复程序在哪里，或者它位于某个主存储库中，您可以在其中合并修复程序。我想说这种方法适用于团队环境。
1) It makes it cleaner by providing the fix closer to the creation of the bug. Thus, if you had multiple clones after the bug, each could pull in the fix changeset(s) which don't include any code related to subsequent changes. It does create a new changeset (tip). You will then want to merge that fix with all clones where relevant.
2) Yes. Because you're cloning the code where the bug was created, the revision history refers directly to the changeset where the bug originated, so it helps document (directly and not just through comments) why the change exists.
3) The changeset will never appear inserted - it must always be merged later in the tree, just as any other clone would be merged.
4) I don't see this approach as diverging from any team approach. In either case, you would need to communicate with the team to indicate where the fix is, or it would be in some master repository where you could merge the fix. I would say this approach is applicable in team environments.
从提供更多信息的意义上来说，它更干净。您最终将得到一个合并提交，它通过其父级向您显示错误引入的确切位置以及删除它的位置。
它也更干净，因为您将有一个提交，该提交仅删除错误并随后处理合并内容。也就是说，当您修复最新版本代码中的错误时，您必须同时修复错误并处理新内容，这使得实际修复的内容变得不太清楚。
It’s cleaner in the sense of being more informative. You’ll end up with a merge commit which shows you via its parents exactly where the bug was introduced and where you removed it.
It’s also cleaner in the way that you’ll have a commit which solely removes the bug and take care about the merging stuff afterwards. That is, when you just fix the bug in the newest version of your code, you’ll have to do both bug fixing and taking care of new stuff at the same time, which makes it less clear, what the actual fix has been.
我更熟悉颠覆，但如果您被允许对“过去”进行更改，那么这意味着您可以更改特定存储库的所有分支。
换句话说，如果您在修订版 100 中犯了错误，并对代码进行了分支，则该错误将在两个分支中持续存在。您可以在修订版 100 中修复一次错误，然后将其传播到两个分支，而不是分别修复两个分支中的代码。
I'm more familiar with subversion, but if you are allowed to make changes in "the past" then that would mean that you can alter all branches of a specific repository.
In other words, if you make a mistake in revision 100, and branch the code, the mistake will persist in both branches. Instead of fixing the code in both branches separately, you could fix the mistake once, in revision 100, and have it propagate down both branches.