Oh, I can see the usefulness of the patch for your use case, but it, as is, would make post-review useless for my use case. Where:

your use case = "The registered mercurial repository on ReviewBoard is the default 'remote' path" 

my use case = "The registered mercurial repository on ReviewBoard is the *local* path of the repository where post-review is being running (as a commit hook)"

I would say that both use cases are valid. A solution that comes to my mind would be to change the line commented below to fall-back to the previous behaviour. So it would return the local path when no default path is found on hgrc. Another solution would be selecting the desired behaviour using a command line argument. I would prefer the later, as it would respect the principle of least surprise.

[An extra feature would be to validate the repository path, using /api/json/repositories/ to retrieve the paths registered on ReviewBoard]

Why return None, when data.strip() [or a local variable holding its value] already has a perfectly valid Mercurial repository path?

[I do not know if it is OK for third-party people (that is, those who are not core developers) to do reviews here. If it is considered impolite or impractical, please say so and forgive me.]

There are small problems on the updated patch, as commented below. But I would like to insist that a command line switch to let the user specify if he wants to use the path of the local or remote depository would be better, because random changes on hgrc would not change the behaviour of post-review. And people using a default "remote" repository could still use the local path (that is not my use case, but it seems possible).

This should be data.strip().

I would also name the variable 'local_repository' or something similar and use it on the line 800 instead of calling data.strip() again.

I think this comment should be keep just after the end of the previous if.

The second parameter of os.path.join should be split in two: '.hg' and 'hgrc'.

I missed this return on the previous review. If the selected strategy is to fall-back to the previous behaviour, this should not be a 'return None'.

Looks good.  Committed to SVN.  Thanks!