Differences between revisions 6 and 8 (spanning 2 versions)
Revision 6 as of 2010-02-10 03:05:24
Size: 3843
Editor: CgLinden
Comment:
Revision 8 as of 2010-02-11 06:47:06
Size: 3945
Editor: CgLinden
Comment: soften the "go as far as possible" paragraph, explaining the main point of going back in time.
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
This should be as far back in the past as possible. The farther back, the better - unless of course a lot of reorganization took place. At minimum, it should be the revision where the bug was found. This should be as far back in the past as reasonable, no need to be religious about it. Ideally, you should select a revision that is present in all of your team members' repos. The tagged revision of the release where the bug was found is often a reasonable candidate - or the revision of the oldest release you still wish to support - if the bug is present there, of course.
Line 40: Line 40:
{{https://wiki.secondlife.com/w/images/3/3b/Hg-dag-7-daggy-fix.png}} [[Image:hg-dag-7-daggy-fix.png]] {{https://wiki.secondlife.com/w/images/3/3b/Hg-dag-7-daggy-fix.png}}
Line 54: Line 54:
{{https://wiki.secondlife.com/w/images/%37/%37%35/Hg%2Ddag%2D%39%2Ddaggy%2Dfix%2Dcorrect%2D%31.png}} [[Image:hg-dag-9-daggy-fix-correct-1.png|]] {{https://wiki.secondlife.com/w/images/%37/%37%35/Hg%2Ddag%2D%39%2Ddaggy%2Dfix%2Dcorrect%2D%31.png}}

The "Daggy" Fix

The daggy fix is a technique to use for fixing small-ish bugs so that other people can choose to cherrypick that fix without necessarily having to pull in all your other changes, and without needing complicated diff/patch or transplant extensions.

It also demonstrates a variety of techniques to operate on the revision graph, and how you can pull only specific changes from other people's repositories.

Locate the revision where the bug was introduced

This should be as far back in the past as reasonable, no need to be religious about it. Ideally, you should select a revision that is present in all of your team members' repos. The tagged revision of the release where the bug was found is often a reasonable candidate - or the revision of the oldest release you still wish to support - if the bug is present there, of course.

https://wiki.secondlife.com/w/images/3/33/Hg-dag-2-daggy-fix.png

You can then use the "hg update" command to place your workspace to that revision, v1.0 in the diagram.

The "hg parents" command is helpful for locating yourself in the revision tree. The name is a little misleading, the way to think about it is: "hg parents tells me what the parents of my checkin would be, if I were to check in now".

Create a named branch

This will allow people to identify your fix later on.

https://wiki.secondlife.com/w/images/3/3e/Hg-dag-3-daggy-fix.png

Note that the branch doesn't really "exist" yet. The hg branch command just tells hg to mark your next checkin as belonging on that branch.

Edit, Compile, Test, Debug

... and commit. This will create a revision on a little branch, as shown:

https://wiki.secondlife.com/w/images/d/d1/Hg-dag-4-daggy-fix.png

Merge fix into your tip

First place yourself on the tip. Merges are directional, and whatever branch your current workspace revision is set to will be the one that survives.

https://wiki.secondlife.com/w/images/0/0b/Hg-dag-5-daggy-fix.png

Now run the hg merge command. Note that you can specify a branch name as a --rev parameter. This means all revisions on that branch - which is usually what you want.

https://wiki.secondlife.com/w/images/1/14/Hg-dag-6-daggy-fix.png

How To Pull In a Daggy Fix

Here we demonstrate how you can get someone else's fix into your repository. You cloned your repository right when v1.0 was released, and started some work, as shown:

https://wiki.secondlife.com/w/images/3/3b/Hg-dag-7-daggy-fix.png

Pulling in the other repository

Now you could just do an "hg pull" of the other person's repository, and you would get this result:

https://wiki.secondlife.com/w/images/e/e8/Hg-dag-8-daggy-fix.png

This may be a little more than you wanted. It is not necessarily bad to do this, but you would have to get comfortable working with multiple heads, and you may end up having to merge unrelated work at an inconvenient time, so this is not really what we want.

If you do this by accident, use "hg rollback" to undo.

Pulling in only part of the other repository

What you should do is specify the branch on the hg pull command, as shown:

https://wiki.secondlife.com/w/images/7/75/Hg-dag-9-daggy-fix-correct-1.png

This will only pull in that one branch. Note that it doesn't pull in the merge revision, since it no longer is part of that branch.

You then simply merge that branch into your current tip. If you also are using a named branch, be careful to "hg update" yourself to the correct head (i.e. your branch) prior to executing the merge. Remember: the branch you're on survives, the other one dies.

https://wiki.secondlife.com/w/images/7/7c/Hg-dag-9-daggy-fix-correct-2.png

Done! You now have the other person's bug fix, without having to merge all of the other person's work!


CategoryHowTo

DaggyFixes (last edited 2011-09-21 18:10:11 by CgLinden)