Mercurial 的任务控制更加困难，因为无法更改错误的提交消息
我以前使用SVN，可以通过在提交消息中添加任务编号来跟踪任务，例如：
-m "Task34: done something"
用于跟踪与某个任务相关的所有更改。提交摘要中的任何错误（确实发生）都可以修改。
然而，在 Mercurial 中，提交摘要无法更改，因此我无法遵循我的任务控制方法。有没有更好的任务管理方法？或者有没有办法改变提交摘要？
I used to use SVN, and I could track the task by adding the task number in the commit message, for example:
-m "Task34: done something"
This is used to track all the changes relating to a certain task. Any errors (which do happen) in the commit summary can be modified.
However, in Mercurial the commit summary cannot be changed, and hence I cannot follow my approach of task control. Is there a better approach for task management? or is there a way to change the commit summary?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Mercurial 是围绕不可变历史的理念构建的。每个更改严格来说都是新更改集的添加。例如，删除某些内容是通过添加逆操作（使用
backout命令）来完成的，这样您就可以在历史记录中记录错误代码及其删除情况（而不是在历史记录中没有记录） 。该模型是一位科学家用笔在编号页上写下他或她的日志，记录成功和失败。
也就是说，基本的 Mercurial 功能不会修改提交消息，即使它们从未被推送过，因为这违背了模型。然而，还有其他方法可以不断修改代码，直到您满意为止。您可以使用 Mercurial 队列，它是可变的覆盖层，其本身可以是不可变的版本。
然而，如果我是你，我只会采用一种包含不变性的工作模式。将问题 ID 放入提交中非常棒——只需继续这样做，并在后续变更集中使用描述中的相同 ID 进行任何更新或更正即可。
然后您将能够执行以下操作：
这将立即向您显示与该任务 ID 相关的所有更改，并且如果其中一些更改“取消了之前的尝试，使用 foobaz 模块再次尝试”，这是一个很好的做法，而不是一个缺陷。
Mercurial is built around the idea of a immutable history. Every change is strictly the addition of a new changeset. For example, removing something is done by adding the inverse (using the
backoutcommand) so you have a record of both the bad code and its removal in history (as opposed to no record of it in history).The model is that of a scientist writing in his or her logbook in pen on numbered pages, recording both successes and failures.
That said, the base mercurial functionality isn't going to make revising commit messages, even if they've never been been pushed, because that goes against the model. There are, however, other ways to keep revising code until you're happy with it. You can use Mercurial Queues, which are mutable overlays, which can themselves be immutably versioned.
However, were I you I'd just adopt a workmode that embraces the immutability. Your putting the issue id in the commit is great -- just keep doing that and do any updates or corrections in subsequent changesets with the same id in the description.
Then you'll be able to do something like:
Which will instantly show you all the changes related to that Task ID, and if some of them are "backed out previous attempt, taking another stab at it using foobaz module" that's good practice not a flaw.