You can access it here.
Instructions on how to use it here.
All patches should be sent to be reviewed, unless you're a VS dev with direct SVN access and the patch is trivial. Even for us devs with direct SVN access, it is recommended we submit the patches for review before committing them (or after), to increase the chances of quickly detecting any problems with new code (and possibly old, related code).
Data changes may not work very well with the tool, so I'll leave it up to the submitter to decide how to review data-side changes. If the changes relate to python scripts or xml files, it should work fine, and submitting them to review should be beneficial. But if it involves images or binary data I'm not so sure.
For units.csv changes, any reviews should be informal (post a patch in the patch tracker, explain what the changes are) and post-commit (commit the changes as soon as they're tested and working), to avoid conflicts and because usualy code review tools don't work well with units.csv.
When creating a new topic for review, set the following fields, besides the usual title and description:
- Repository: must be vegastrike SVN. CVS isn't used anymore.
- Project: pick an appropriate project, depending on what your patch is about.
- Reviewers: minimally: klaussfreire, pheonixstorm. You can add others too.
- Cc: Should we create a mailing list perhaps?
- State: Leave Open
- ship it or LGTM (looks good to me), to approve the changes
- don't commit to reject them - ie, if you find a game-breaking bug
- PTAL (please take another look), if you made changes or if you're requesting a re-review of your code