Mercurial: what is the benefit of fixing bugs in earlier versions
According to the guide under the heading Bug fixes in earlier versions , it says the following:
When you find a bug in some earlier version, you have two options: you can either fix it in the current code, or go back in history and fix the code exactly where you did it, which creates a cleaner story.
- How does the past in history make it cleaner? He's still making a new set of changes at the tip.
- Does this have anything to do with what is recorded as parent?
- Is there a way to view the logs seeing the recently inserted changeset in this order?
- This tutorial is under the main heading Lone developer with non-linear history . Is this good practice when working in a team?
a source to share
1) This makes it cleaner by providing a fix closer to creating a bug. That way, if you had many clones after a bug, each one could pick up a set of fixes (fixes) that do not contain any code associated with subsequent changes. It creates a new changeset (hint). Then you will want to combine this fix with all clones where needed.
2) Yes. Since you are cloning the code in which the bug was generated, the changelog refers directly to the changeset in which the bug occurred, so it helps to document (directly, not just through comments) why the change exists.
3) A changeset will never be inserted - it must always be merged later in the tree, just like any other clone would be merged.
4) I do not see this approach diverging from any team approach. Either way, you will need to contact the team to point out where the fix is located, or it will be in some main repository where you could merge the fix. I would say that this approach is applicable in a team environment.
a source to share
It's cleaner in the sense of being more informative. Youll end up with a merge commit that shows you through your parents exactly where the error was introduced and where you removed it.
It is also cleaner in the way that you have a commit, which only removes the error and takes care of the merge afterwards. That is, when you are just fixing a bug in the newest version of your code, you have to do the bug fix and take care of the new stuff at the same time, making it less clear what the actual fix is.
a source to share
I'm more familiar with subversion, but if you are allowed to make changes in the "past", it means that you can change all branches of a particular repository.
In other words, if you make a bug in revision 100 and deploy the code, the bug will persist in both branches. Instead of fixing the code in both branches separately, you can fix the bug once, in revision 100, and propagate it to both branches.
a source to share