Add support for closing and submitting reviews

Review Request #1479 — Created March 19, 2010 and discarded




* Add --submit, -s: for submitting code and marking the code as submitted
* Add --discard to allow discarding from the CLI
* Add 'def submit(self, server, changenum, files):' function to all SCMClients
** Add functionality for subversion (I don't have time right now to hunt down
   all the supported SCMs and patch for them).
*** Includes the Review URL, bug list, reviewers, approvers and description
    in the message sent to subversion.
* Add close(): to aid in closing a review
* Add get_review_url(): centralize code to collect this information
** Point users of this code to the function
* Add get_approvers(): List of people who have clicked 'ship it'
* Add get_reviewers(): List of people who have submitted reviews
* Add get_description(): Get the description held by reviewboard
* Add get_bugs(): List the bugs tagged with this review

  1. Thanks for the change. We're in feature freeze for RBTools, but I'll look at this once we've released.
    1. RBTools 0.2 has been out for a bit, so I'm wondering if you've had a chance to look at this yet?
  2. rbtools/ (Diff revision 1)
    Should just be:
    if review['ship_it']:
  3. rbtools/ (Diff revision 1)
    Should explicitly use 1 or 0 based on the value of ship_it.
  4. rbtools/ (Diff revision 1)
    I know you guys want this, but we can't put this into post-review as it is today. This is very specific to your setup and it'd be too difficult to really support various setups with this.
    I'd rather see effort spent on breaking up post-review into a bunch of smaller apps that each do one thing (close a review request, get the list of reviews, etc.) and then it'd be easier to have a custom commit script that does the right thing.
    1. One thing I was thinking of is that we could potentially have a template defined in the .reviewboardrc file that contains variables such as $(bugs) and such. We could render the template outside of the SCMClient classes. Then the submit function would just take the rendered commit message and commit that.
      There are SCMs where this perhaps makes a little less sense, and in some cases you don't actually want to use the commit message as-is (such as submitted patches to our project where you want to refine things first) but that's probably fine.