Differences between revisions 3 and 4
Revision 3 as of 2010-11-15 19:41:00
Size: 2983
Editor: MalteHelmert
Comment:
Revision 4 as of 2010-11-15 19:45:31
Size: 2984
Editor: MalteHelmert
Comment:
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:
 * Writing a Mercurial extension (or plain shell script) that automatically calls Rietveld's {{{upload.py}}} with the appropriate info for [[../Workflow|our Mercurial workflow]].  * Writing a Mercurial extension (or plain shell script) that automatically calls Rietveld's {{{upload.py}}} with the appropriate info for [[../Mercurial|our Mercurial workflow]].

Back to developer page.

Code reviews with Rietveld

We are using (or planning to use) the Rietveld code review tool.

There are various fancy ways in which Rietveld could be integrated into our infrastructure (repository, issue tracker), such as:

  • Hosting our own instance of Rietveld rather than the one hosted by Google.

  • Writing a Mercurial extension (or plain shell script) that automatically calls Rietveld's upload.py with the appropriate info for our Mercurial workflow.

  • Writing a Roundup plugin that identifies patches that are attached to an issue and automatically creates and links a matching Rietveld issue.
  • Writing a Mercurial extension that automatically uploads a patch to Roundup attached to the appropriate issue (from where a Roundup/Rietveld integration plugin could take over). Could also go the other way: automatically fetch a patch from an issue and apply it.
  • Automatically matching up our Roundup users to Rietveld users, or automatically matching up our Mercurial users to Rietveld users (e.g. linking the nosy list of an issue to the "reviewers" of a Rietveld issue.)

For now, let's leave these as potential avenues to explore in the future and stick with using Rietveld manually until we've got the hang of it.

Using Rietveld manually

To get set up, download Rietveld's upload.py with

wget http://codereview.appspot.com/static/upload.py

and store it somewhere on your path. Don't forget to make it executable.

To create a patch:

  1. hg update to the "new" version of the code that is to be reviewed. If you're working on issue1000,

    hg update issue1000
    should do the trick.
  2. Find out (using hg log, hg parents etc.) which "base" version of the code this should be reviewed against. Normally this would be the parent of the first revision on your branch, which you can find out with

    hg parents -r $(hg log --branch issue1000 --template '{node}\n' | tail -1)

    (Is there an easier way?) Let BASE be the changeset identified in this way. You can use either the local numeric id or the global hash.

  3. Optionally, run

    hg meld -r BASE

    and verify that you picked the correct BASE revision. (If you haven't set up hg meld yet, see ../Mercurial.)

  4. Run

    upload.py --rev=BASE
    to create a Rietveld issue.
  5. You'll have to answer some questions. When queried for your email and password, use ones that are tied to some Google account (e.g. that you use for Google groups); they don't have to be gmail/googlemail addresses.

  6. You'll see a line like

    Issue created. URL: http://codereview.appspot.com/XXXXXXX
    that provides the URL for the newly created issue. Send it to the potential reviewer or go to that page to invite a reviewer via Rietveld's web interface.

FastDownward: ForDevelopers/CodeReview (last edited 2020-07-09 08:47:09 by SilvanSievers)