hg review - a useful bun for mercurial
Git has GitHub, and Mercurial has hg review. In fact, I compared the goat with the boyfriend.
Review code.
If you were looking for an open, free, fast, small, convenient, and beautiful system for reviewing a code, then most likely you failed. From existing projects, I watched ReviewBoard, but, like everything created by cool companies, it is difficult to install, configure and implies a behavior scenario that is not quite familiar to us.
And then a project appeared that gives us a tool, and how to use it is up to us.
Total:
- Post-commit review
- Distributed architecture
- Web interface
- Pleasant (!) Appearance.

Installation
Installation takes place as all other non-built-in extensions for mercurial:
')
> cd some_cool_place
> hg clone bitbucket.org/sjl/hg-review
We add to our ~ / .hgrc:
[extensions]
review = [path to]/hg-review/review/
Is done.

Customizable.
First I’ll say that hg review works like this:
We have to create a kind of public repository, where all developers can put / take the code.
Next, we activate support for the code review for our main repository and, at the same time, specify our public repository for storing all reviews.
When working, hg review, will take the code for review from our main repository for development, and all comments will be placed in the repository for review.
Why is it done this way? Because it is not allowed to clog our main repository with unnecessary commits. After all, during his work he will generate a certain set of files, and in principle each comment could cause a commit.
Instead, when initializing, your repo will create a .hgreview file, with one single line: pointing to the repository for storing the review. Plus, the review directory will be created in your local repository, in .hg /, which will produce a working copy of this remote repository for the review.
That is, to ensure all performance, our main repo will suffer only once, when there is a commit with the creation of .hgreview
This file is necessary so that other developers would not bother with the supported hg review.

We move to some existing repository, where we want to review the code.
> hg review --init --remote-path [url-of-remote-public-review-repo]
Is done.
The rest of the developers will do enough once:
> hg review --init
This command, based on information from .hgreview, will create a hidden repository and prepare everything for work.
Now to use the system, we will run
> hg review --web
when we need. All actions necessary for the functioning of the system can be performed from the web interface. Add comments, click “push to default” and our comments will get into the public repository for review. Accordingly, in order to pick up new comments, we do a “pull from default”.
We use
So, the main features that gives us hg review:
- Comments for changesets
- Signatures (yes / no / neutral) for changesets
- The most interesting: comments for the code lines from the changeset.
Having these opportunities, the organization of a specific workflow, is already our hands.
We can comment on someone else's code, read comments for our code, synchronize these changes, using the web interface.
The project is relatively young, mostly done by one person, but what is already now gives hope that we will get a very, very useful tool.

Disadvantages (hopefully temporary).
We have found several flaws so far, among which are:
- Relatively slow work. For their work, only simple means are used (text files that are best supported by VCS) and the means of the mercurial itself, such as commit, push, pull, which is very ideological and correct. Let's just hope that there are ways to increase responsiveness. But all this is not critical for the army. I guarantee it!
- You can edit comments left by another user. There is no authorization tool, since user identification is based on username from the mercurial settings file. In addition, for not at all good, a warning: since mercurial adheres to the principle of immutability of history, it is not possible to remove the mention of comment editing. it can be tracked if you look at the hg log in the review repository.
Perhaps help.
- If you don’t see the changeset’s change changes, check that you’dn’t have diff = git in .hgrc

References
Demo:
review.stevelosh.comRepository:
bitbucket.org/sjl/hg-review/srcDocumentation:
sjl.bitbucket.org/hg-review