Mercurial (hg) SCMTool

Review Request #97 — Created June 22, 2007 and submitted


Review Board SVN (deprecated)


Update 2007-08-09:

Moved fixture data into its own JSON file. Catch up with upstream changes. General clean up.

The tests now use a hg repo in testdata/hg_repo, which I couldn't attach to the patch. I have emailed a tarball to David.

Update 2007-08-06:

Uploaded a new diff to use the new DiffParser per Christian's comment.

Update 2007-07-17:

Uploaded a new diff that addresses the issues noted by Christian.

Also, a small fix to the parsing of diffs that create files, and a small change to make us compatible with Mercurial 0.9.4 (repo.LookupError moved, so I use a more general and hopefully stable exception).



Uploaded a new diff that fixes the style/whitespace issues noted.

Now applies against rev 773 (in particular, the rename of SCMException to SCMError).

I've also cleaned up the handling of diffs that create files, and overridden a more sensible method in DiffParser.



Uploaded a new diff that now applies against the DiffParser patch ( directly, rather than against the GitTool patch.


A very tentative attempt at Mercurial support for reviewboard.

This patch is based on Nick Loeve's git scmtool ( NOTE that it depends on the changes to DiffParser in that patch (so that HgTool can provide a parser for hg-style diffs).

If anyone is interested, I have a mirror of the reviewboard source in mercurial ( and a Mercurial Queues repo containing this patch and the git one it depends on (
Update 2007-08-09: tests working again--all tests passing. 

Update 2007-08-06: the tests are currently broken, due to an upstream change to django. I'm working on getting them fixed.


I have it talking to a Mercurial repository and correctly reading diffs.

There are basic unit tests for the diff parsing and other supporting methods.

I had to remove the test that actually retrieved a file from a repo, since I haven't found a good way of getting a repo into a patch (the .hg dir contains binary files). I suspect that the answer will be to create the repo dynamically as part of the fixture setup. (I have a rough version of this working, but it's not in this patch due to being *very* rough).
  1. Most of this looks pretty good.
  2. trunk/reviewboard/scmtools/ (Diff revision 2)
    Separate these onto two lines (python style guidelines)
  3. trunk/reviewboard/scmtools/ (Diff revision 2)
    This shouldn't be necessary for your tool
  4. trunk/reviewboard/scmtools/ (Diff revision 2)
    Trailing whitespace.  I'll only mark this one, but you've got a few of these spread around -- just look for red blocks in the diff viewer here.
  5. trunk/reviewboard/scmtools/ (Diff revision 2)
    If Hg doesn't have a concept of changesets the way that perforce does, you probably don't need these for now.  At the moment, this is just used for retrieving log information from the VCS for a revision that hasn't yet been committed.
    1. Hg does have a concept of changesets--in fact it's the central concept. But it doesn't have the idea of pending changesets, so if that's the only way it's used it's probably not relevant right now.
      What I'd like to be able to do is review a changeset (rather than a diff). With a distributed SCM like hg, it is a reasonable workflow to have a shared "intergration" repository to which developers push changes for review (and when a change is accepted, it can be pushed "upstream" to a release repo).
      Ideally, you would create a new review for a changeset id, rather than upload a diff. I will have to look more deeply to see if this is possible. I imagine the sames ideas could be applied to Nick's git backend also.
    2. Yeah, this is probably where the LocalFile backend would come into play.  The existing backends are for showing diffs against files committed to some central repository.  If you want to show a diff against file versions that only exist in your local clone of the centralized repository, you'd need to upload a copy of the source file along with the diff.
    3. I was trying to say the opposite. :) With mercurial, you can push your changes (roughly equivalent to committing in a centralised SCM) to another repo, which could be the one that reviewboard uses. Then, you can create a review request that gets its diff directly from that repo, based on a changeset id.
      I have this roughly working now, so I'll upload a new diff once I've cleaned it up.
  6. trunk/reviewboard/scmtools/ (Diff revision 2)
    Two blank lines between classes, please (here and below)
  7. trunk/reviewboard/scmtools/ (Diff revision 2)
    We should be able to add binary files to the svn repository just fine
    1. Yeah, and I should be able to add them to an hg repo just fine... but somehow moving them around as patches was breaking. I will look into it some more.
  2. trunk/reviewboard/scmtools/ (Diff revision 4)
  2. trunk/reviewboard/scmtools/ (Diff revision 4)
    Can you alphabetize all this?
  3. trunk/reviewboard/scmtools/ (Diff revision 4)
    Variables should go after the __init__ call.
  4. trunk/reviewboard/scmtools/ (Diff revision 4)
    Go ahead and just remove this function. It's not used and will probably go away.
  5. trunk/reviewboard/scmtools/ (Diff revision 4)
    Can you change the indentation of the text to be the same as the """ ?
  6. trunk/reviewboard/scmtools/ (Diff revision 4)
    The second if should be elsif.
  7. This should probably be part of the default fixture.
  8. trunk/reviewboard/scmtools/ (Diff revision 4)
    Two lines before the class.
  9. trunk/reviewboard/scmtools/ (Diff revision 4)
    Can you fix the indentation of the parameter?
  10. trunk/reviewboard/scmtools/ (Diff revision 4)
    Might be nice to have a utility function in the class that takes the diff contents and returns the result of parse()[0], so that we don't duplicate it everywhere.
  11. trunk/reviewboard/scmtools/ (Diff revision 4)
    Please fix the indentation of this comment.
  12. trunk/reviewboard/scmtools/ (Diff revision 4)
    A lot of these should be one-liners.
    1. What's the project standard for max line length? Some of them would be 80-90 on one line, so I'll leave those ones wrapped for now.
    2. Roughly 80. Preferably before around 75, 76.
  2. trunk/reviewboard/scmtools/ (Diff revision 5)
    You can remove this.
  3. trunk/reviewboard/scmtools/ (Diff revision 5)
    Perhaps send us a tarball of the binary files for this?
    1. Emailed to David.
  2. trunk/reviewboard/scmtools/ (Diff revision 5)
    This will now need to be updated to work with the new DiffParser changes in SVN (r852). You can find the review request for this on the All Review Requests page for docs on how this now works.
    1. New diff uploaded.
  1. This looks good to me.  Is there anything more to do before this goes in?
    1. It's complete, as far as I can tell. Working fine here. :)
    2. I've just committed the patch and test repo, and will close out the review request.  Thanks for your hard work on this!