So what can you do with Rietveld? The basic workflow is:
1. Developer makes some changes in their Subversion workspace.
2. Developer uploads a patch in the form of svn diff output to Rietveld, using a small script named upload.py. This creates a new issue for them on the Rietveld website.
3. Developer goes to the issue that was just created on the Rietveld site, adds the email addresses of one or more reviewers, and causes Rietveld to send an email to the reviewer(s).
4. Reviewer navigates to the issue on the Rietveld site, browses the side-by-side diffs linked from there. A side-by-side diff shows the old and new version of the source code side by side, with deleted text on the left marked with a light red background, and inserted text on the right marked with a light green background. (Two different shades of red and green each are used, to highlight the differences at a finer-grain level than blocks of lines. This helps find one-character changes and clarifies diffs that just reflow a lot of text.)
5. Reviewer inserts inline comments directly into the side-by-side diffs, by double-clicking lines on which they want to comment. Inline comments are initially created in draft mode, which means that only the comment author can see (and edit) them.
6. Reviewer publishes comments, making them visible to everyone else, and sending an email to the developer (and to other reviewers) summarizing the inline comments with a little bit of context.
At this point, the developer can reply to inline comments directly on the Rietveld website using exactly the same mechanism as used by the reviewer. Replies simply become additional inline draft comments. The developer can also revise their code and upload a new version of the patch. The new version is attached to the same issue, and reviewers can choose to view the diffs afresh, or view the delta between the new and the old version of the patch. The latter feature is particularly helpful for large code reviews that require several iterations to reach agreement between developer and reviewer: the reviewer doesn't have to re-review stuff that didn't change between revisions and was already approved.