RSS
 

TortoiseHg Review Board

The TortoiseHg review board dialog is a graphical user interface that is integrated into TortoiseHg 2.0. It controls a Mercurial extension of the same name and allows you to easily post a review directly to your review board installation from the TortoiseHg workbench with a few simple mouse clicks.

Minimum Requirements

.

Installation

First you will need to install TortoiseHg 2.0. Information on how to install and use TortoiseHg can be found at http://tortoisehg.bitbucket.org/manual/2.0/index.html

Once installed you will need to download the mercurial-reviewboard extension from the link above configure your .hgrc to enable the extension by adding following lines:

[extensions]
reviewboard = /path/to/reviewboard

.

Options

The review board  dialog has three options

1. Create diff with all outgoing changes

This option will grey out the change sets list and  select only highest selected revision. It will create a diff with all the outgoing change sets from the selected revision.

The option could be used if you have many new change sets within the workbench and wish to include them all in a diff. Using this feature means that you will only need to select one change set instead of them all.

2. Create diff with all changes on this branch

This option will also grey out the change sets list,  as above, and will create a diff of all changes on the named branch of the selected change set, not just the outgoing ones.

The option could be used when you want to create a new feature with its own named branch and wish to send all the changesets of said feature branch to review board.

Be careful with this option because if you select a change set on a main development branch it will include all changes from the selected change set back to where the branch was first created. This could create a very large diff!

Note: The option refers to a named branch should not be confused with a divergence in a line of development.  Please see the Mercurial Branch page for more information – http://mercurial.selenic.com/wiki/Branch

3. Publish immediately – This one is self explanatory, the review will not be posted as a draft.


Tutorial

First you will need to set up the Review Board extension settings in the TortoiseHg settings dialog under the Review Board tab. The Review Board server and username is required because the dialog will get a list of repositories and existing review requests from the server when the dialog is opened. The password is optional, however if you enter it here you will not be prompted for it later.

Important Note: the password will be stored in clear text so if you are worried about security do not save your review board password here.

Once the settings are correct you are now ready to post a review to the Review Board server. To do so, you will need to select an outgoing change, or multiple outgoing changes, from the TortoiseHg Workbench and click the right mouse button to display the context menu. From here you can select Post to Review Board that will open the Review Board dialog.

Within this dialog you can set up the review that you wish post to the Review Board server. You can choose to post a new review or update an existing review. You will also see a list of the change sets that you selected within the workbench.

If the ‘outgoing’ option is not checked the review will contain the change sets from the top to the bottom checked change set. For example, if there are 5 change sets in the list and the first and last are not checked then the review will include change sets 2, 3 and 4 regardless if change set 3 is checked or not.

You can also choose between some options depending on if you are posting a new request or updating a new one.

.

.

.

.

.

.

.

The review description will contain a list of the change sets posted and their commit messages.

Leave a Reply

 

 
  1. Brian

    August 21, 2016 at 6:56 am

    Hi Mikey,

    We’ve been struggling to get this working. We installed Mdelagra’s fork and setup our .hgrc file and now see your extension in the right click menus. However when we click on it we always get an HTTP Error: NOT FOUND . Pressing ok closes the dialog. We are using http://oursite/ for the server address, which works using the browser. Is there any logs or something we can use to diagnose the problem?

    P.S. your contact link/page is hacked

     
  2. Hocine

    June 1, 2015 at 7:01 am

    Hi Mikey,

    Tanks for your great job. The mercurial’s review board plugin doesn’t require the username
    `# OPTIONAL ITEMS:
    # user = … # username for login`
    `
    But your gui require it. I think that’s not consistent.

     
    • Mikey

      June 1, 2015 at 9:18 am

      Gday Hocine,

      Thanks for your feedback!

      It is required in the GUI because the username is used to populate the existing requests combo box.
      Unfortunately, yes, its inconsistent, however when it is not supplied in the command line version the user is prompted for it anyway.
      So I felt it was easier just to force the user to take this small step and supply the user name for a nicer UI experience.

      Cheers,
      Mikey

       
  3. Ashith

    May 6, 2015 at 5:09 pm

    I have reviewboard installed on a https server which has a self signed certificate created using OpenSSL. Whenever I use your dialog or hg postreview to post reviews to this https server I get a HTTP Error: Basic authorization failed.

    When I test with HTTP server I am able to post requests. Do I have to shift my reviewboard server to plain http rather than secure https?

     
    • Mikey

      May 8, 2015 at 9:09 pm

      Gday Ashith,

      I cannot answer that question because my GUI tool uses the mercurial-postreview plugin. You would be better off forwarding it to the authors of this plugin here – https://bitbucket.org/mdelagra/mercurial-reviewboard.

      Cheers,
      Mikey

       
  4. Brian Ackermann

    April 9, 2015 at 1:52 am

    Ok, fair enough, you win !! :)

    I added the following code to your postreview.py script, and then regenerated my library.zip file…

    myCmd = ['postreview'] + cmdargs(opts) + [revstr]

    r = qtlib.QuestionMsgBox(_(‘really’),
    _(‘perform\n%s\n?’) % myCmd)

    The output from that basically confirmed what you had said, I needed the –outgoing flag, and helped me correct another error I’d made. Now my cmd looks like this

    > hg postreview –outgoing -p tip

    and all is working. I still have no idea why the other was failing, but I’m content at this time with a working solution.

    Thanks ever so much for the pointer!

     
    • Mikey

      April 11, 2015 at 10:12 am

      Gday Brian,

      You are quite correct. They are not mutually exclusive and I agree that every piece of code should get submitted to review board that is to be pushed up steam. However a post commit hook would not work for me because not every commit that I make is ready for review. This is the goal of my dialog coupled with the Mercurial post review plugin, it allows the developers to post to review board from the TortoiseHg workbench when their work is ready for review, be it one commit or many.

      I don’t actually maintain the Mercurial post review extension, instead I just submit fixes to any bugs I come across. The the Thg dialog I use the ‘–outgoing’ option by default because, without it, the plugin is not as stable. To be honest, I cant think of a reason why you would not want to diff the local repo with the upstream one in the first place.

      Looking at your original command line args I can’t really see why it was failing but it is good to see you found a work around.

      Cheers,
      Mikey

       
  5. Brian Ackermann

    April 8, 2015 at 10:40 pm

    I’m not sure I agree that ‘code review’ and ‘commit early and often’ are mutually exclusive propositions! :D For our part, we need to review every piece, and a postcommit hook seems the easiest way to guarantee that a review-request is sent off to reviewboard. For me personally, I don’t much care if its every commit, or every 5, or some other scheme, but I do care that all changesets are reviewed.

    The problem I see with –outgoing is that it would be possible for me to push unreviewed changesets at some point, so that a subsequent –outgoing call would not generate a review on the ones that were unreviewed but already pushed out. Doing it commit-by-commit seems to get around this detail nicely, and automates at the same time, which I much prefer to the alternative. Another difficulty that I have with that is that the UI does not make the same demand, but I expect that is just a miscommunication between us.

    Now, as to specifics, you mention that I might use –outgoing, but I think that is not where my problem is. In looking at the (mercurial-reviewboard) code, it looks as if, to get a ‘remote parent’, I need to specify -o , -O, or -m options. For a single, most recent commit, it appears that ” -m tip ” does the job quite nicely. And, indeed, once I figured THAT bit out, I got a good deal closer, and with the –debug flag on, I am now seeing the generated diff files “parent to rev” and “rparent to parent” as I expect them to do. My command follows:

    C:\work\webstore\ws_trunk>hg postreview -m tip –username=brian –password=password –debug -p

    postreview plugin, version 3.5.3
    remote parent: 89980e16b1a4
    parent: 01166473cacd

    Ultimately, it throws a “400: Bad Request” error at me from the url : (I added my own tracing to the functions to see where it was dying)

    ######### url = http://server:5555/api/review-requests/112/diffs/

    I’m not really sure where to go from there, as there don’t seem to be any details available to me as to WHY the apiRequest failed.

    Thanks…

     
  6. Brian Ackermann

    April 8, 2015 at 7:10 am

    I am having a bit of a problem, and I’m hoping you can at least point me in the right direction. What I started out trying to do was to write a postcommit hook to bring up your fancy new dialog. But I’ve been unable to do that.

    So, I instead figured that I didn’t really need your fancy dialog for a postcommit reviewboard ‘post’, and that I would try to get by with just using the “hg postreview ….” commandline. Unfortunately, I must have something wrong, because, when I run my command, it fails with a generic 400 Http error when trying to upload the diffs.

    But, if I DO use your dialogs, and set up the same push, yours goes through perfectly.

    As far as I know, your dialogs ultimately use the same postreview plugin that I’m using (right?), so the only think I can think of is that I’m missing someting on my commandline setup.

    Do you have any advice on where I could look for a solution? Any way I can get the output of what your dialog generates for a command? If i could see that, I bet I could analyze it for what I’m missing pretty easily.

    Thanks!

     
    • Mikey

      April 8, 2015 at 9:31 am

      Gday Brian,

      It seems odd that you would want to post a review for every commit because it kinda goes against the mantra of distributed source control; namely ‘commit early and often’.

      Regarding your issue. You will need to make sure you use the ‘–outgoing’ or ‘-o’ option to get your outgoing change set.

      Do you get the same error when you post review directly from the command line within your repo?

      Regards,
      Mikey

       
  7. Eric McKinlay

    March 22, 2015 at 2:51 am

    Mikey,
    Another quick question:
    There does not seem to be a way to compare (and submit to RB) a diff between uncommited changes (the contents of the working directory) and a revision. Am I correct that this is not supported? This is not a huge deal (arguably any changes worth reviewing ought to be check in to the local repo anyway), just curious.
    Eric

     
    • Mikey

      March 22, 2015 at 9:09 am

      Gday Eric,
      There is no current functionality to diff the uncommitted changes. There is no reason it cant be added, however like you mentioned, I think it goes against the mercurial workflow where changes should be committed locally before review.

      FIY – I have submitted a patch to TortoiseHg fix the issue with the settings button that is included in the nightly builds and will be in 2.0.3.

      Cheers,
      Mikey

       
  8. Eric McKinlay

    March 22, 2015 at 2:43 am

    Mikey,
    Thanks much for the quick response. The tip for submitting a diff between two arbitrary revs is especially useful. I am VERY glad that there is a way to do this since this would have been a deal killer for us.
    Keep up the good work!
    Eric

     
  9. Eric McKinlay

    March 19, 2015 at 10:58 am

    Looks like there are a very limited set of options for generating the diff for RB using the Extension from mdelagra. Basically looks like you can:
    - Compare the tip with the last committed version (no checkboxes checked)
    - Compare the tip with the earliest version in the local repo (Creat e diff with all outgoing changes checkbox checked)
    - Compare the tip with the root of the current branch in the local repo (“Create diff with all changes on this branch” checkbox checked)

    A couple of questions:
    - Have I summarized the functions related to the checkboxes correctly?
    - Is there any way to specify other types of diffs? (for example, compare the tip with rev x)
    - What is the function of the Settings button on the RB extension dialog. On my system it doesn’t seem to do anything!

    Any help would be greatly appreciated!

     
    • Mikey

      March 20, 2015 at 10:57 am

      Gday Eric,

      - Have I summarized the functions related to the checkboxes correctly?

      Yes you have, althrough I never use the branch option because my branches are usualy very large.

      - Is there any way to specify other types of diffs? (for example, compare the tip with rev x)

      You can diff between two revisions by selecting multiple changesets in the TortoiseHg workbench. This is done by selecting one and then shift/ctrl clicking another before right clicking to load the context menu. Doing this will use the lower numbered changeset as the diffs base and compare it with the higher numbered changset you selected.

      - What is the function of the Settings button on the RB extension dialog. On my system it doesn’t seem to do anything!

      It appears that you have uncovered a bug here because that is supposed to open the TortoiseHg settings tool.

      You are correct in saying the reviewboard extension has a limited set of functionality. However in saying that, it has been good enough for my collegues and I to use on a daily basis. There are few more things I would like it to do and when I get some time I’ll have a go at implementing them to the extension.

      If you need any help, or have some suggestions, don’t hesitate to give me a hoy!

      Cheers,
      Mikey

       
  10. Steve Hebert

    January 25, 2015 at 7:17 pm

    I see that tortoise downloads have version 1.9.1 listed on the site you mention. Does your extension work with this version?

     
    • Mikey

      January 25, 2015 at 11:35 pm

      Gday Steve,

      Yes 1.9.1 does have the Review Board dialog included because it is the beta version of TortoiseHg 2.0 due for release on March 1st.

      Cheers,
      Michael