in other words, how i screwed up a hg push. I wanted to push changes from mozilla-central to mozilla-1.9.2. The standard way is to:
=============================================================
how to apply a m-c committed patch to a release branch
=============================================================
hg qimport http://hg.mozilla.org/mozilla-central/raw-rev/
hg qpush
hg qref -e # add approval information
hg qfin .
hg push
What I did was basically the same thing, with a few shortcuts (insert your favorite story about how cutting corners can cause harm).
Basically I started out with a bug report. It has the information about what it fixed, who reviewed it, who approved it, etc. The first thing to do is verify that it all checks out and is a reasonable thing to do. In the bug, there usually a comment with the hg changeset information. Here was my first shortcut; I copied the url to the html version of the changeset from the bug, and run the qimport command. `hg qimport` has no problem with importing that patch (which should probably generate an error, but anywayz). What this did was imported a big html file — not what I wanted at all.
I then jumped over the `hg qref -e` command. This would have allowed me to see the changeset’s original comment. I would have been able to see that the qimport terribly failed. Also, this is a good idea to do so that you can add the appropriate a=foopy approval flag(s).
The last shortcut I took was I didn’t do a sanity check by running `hg out -p` which would have shown me what I was pushing. This is always a good idea to see what you are pushing. Sure reliance on the tools is fine and dandy, but actually seeing what hg thinks it is going to push doesn’t hurt and only takes a few seconds.
3 shortcuts resulted in a skidmark on the 191 push log:
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/739c7a69d412
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/1898753917d5
Sure there are worse things (e.g. patch bomb, pushing without testing, breaking trees), but I thought I would write this up both for clarification of how I messed up as well as a warning. 
3 Comments
It would be nice if hg noticed that the URL ended in /rev/ and automatically substituted /raw-rev/. I’ve made the same mistake a few times myself but have been lucky enough to notice before pushing.
I suppose I could write a local hg hook, but it would be better if it existed on the server so that others don’t get burnt.
Their was an other small mistake:
“problem important that patch”
Doing extra checks on checking feels redundant, it’s the next step any good programmer needs to do (atleast in a bigger project) and the first step in doing good deployment.