If this is the first time any of these changesets have been seen, then we create a new Code Review (using the Code Collaborator command line), and then record these changesets in the database with that code review's ID.(The table matches the hash of a changeset with a code review ID). It then queries a database we built to see if those changesets were included in a code review. The hook runs and grabs a list of all the changesets included in the transaction (by running HG log).The developer initiates a push to the stable repository (yes, this really is the first step).
We leverage the fact that when this hook runs, it can see the repository as-if the code changes were permanent, yet also gives us the ability to prevent the push. To enforce the code review, we wrote a pretxnchangegroup hook (documented in the HG Book). (This is significant because we also require that our stable repositories contain the code that is currently running in production, differeing only by pending code promotions.) We require that code be reviewed before it is pushed into a stable repository. We separate stable repositories from development repositories. Likewise, when the development cycle is complete, code gets pushed into the appropriate repository there also. When developers want to "check out" code, they go to this server and clone from the repositories there. We keep a central definitive copy of all our repositories on one server. We actually went through nearly the exact same thing at my company recently.