📜 ⬆️ ⬇️

Review code in mercurial

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.



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:

review = [path to]/hg-review/review/

Is done.



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:

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:

Perhaps help.


Demo: review.stevelosh.com
Repository: bitbucket.org/sjl/hg-review/src
Documentation: sjl.bitbucket.org/hg-review

Source: https://habr.com/ru/post/104239/

All Articles