If we want to stay on Mercurial the best way to review is pre-commit reviews. Rietveld has the best usability of all tools I know, and there are not many tools around.
But Rietveld is no longer maintained. So we need to maintain at least its functionality by ourselves. This is a challenge, as we maintain already a lot of our infrastructure.
But IMHO all hassle we have, is because we use Mercurial in the first place.
We need pre-commit reviews only, because once a commit is done, it stays immutable in Mercurials commit history.
Other VCS like git have a different approach to immutability, which is not immutable per se. They use a Pull-Request workflow made of disposable dev-branches. And these VCS let the maintainers decide the quality of the commits and the history. Here the quality and consistence of the commit history depends on maintainer discipline.
There are many tools and web services like SCMs around the Pull-Request workflow and git. Once a pull request is “LGTM”, it can be squashed to one single commit and applied to the trunk.
Pull-Requests can be discussed line by line. And every iteration of the code evolution is visible in a new commit in the pull-request-dev-branch. IMHO it has a similar visibility and usability like the patch sets and the line comments in Rietveld.
The pull-request approach is very common to programmers nowadays.
But the git and pull-request-workflow is not for free: migration from mercurial and a new set of tools, routines and documentation is a challenge, too.
I constantly ask myself, which approach is better and more “future-prove”? What do you prefer?