|
Size: 3698
Comment: update rietveld instructions
|
Size: 956
Comment: Fix name and remove Rietveld instructions.
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| You can prepare a code review by making a pull-request in your own Fast Downward repository on Bitbucket. | You can prepare a code review by making a pull-request in your own Fast Downward fork on Github. |
| Line 16: | Line 16: |
= Code reviews with Rietveld = We have also been using the [[http://code.google.com/appengine/articles/rietveld.html|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 [[http://codereview.appspot.com/|the one hosted by Google]]. * Writing a Git hook (or plain shell script) that automatically calls Rietveld's {{{upload.py}}} with the appropriate info for [[../Git|our Git 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 Git hook 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 Git 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: /!\ The following instructions are untested for Git. 1. {{{git checkout}}} to the "new" version of the code that is to be reviewed. If you're working on issue1000, {{{ git checkout issue1000}}} should do the trick. 1. Find out (using {{{git log}}}, 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. Let {{{BASE}}} be the changeset identified in this way. You can use either the local numeric id or the global hash. 1. Optionally, run {{{ git diff BASE}}} and verify that you picked the correct {{{BASE}}} revision. 1. Run {{{ upload.py --rev=BASE}}} to create a Rietveld issue. 1. 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. 1. 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. |
Back to developer page.
Code reviews with Github
You can prepare a code review by making a pull-request in your own Fast Downward fork on Github.
Prepare your issue or feature branch (e.g. issue123) according to our Git workflow.
- Push your Fast Downward repository to Github and navigate to it in your browser.
Click "Pull requests" and click "New pull request", then select the main branch of your repository on the left and the issue123 branch on the right.
- Click "Create pull request".
- Link to the pull request from the issue tracker.
Compare arbitrary revisions
Compare any two revisions by following the steps above but using the commit IDs of the commits you want to compare instead of the branch names. It is not possible to create a pull request this way because merging might not make sense for the selected commits but you'll be able to see the code difference.