Improvements to post-review error-handling with Perforce

Review Request #1886 — Created Nov. 1, 2010 and submitted

Information

RBTools

Reviewers

A handful of changes to improve error handling in post-review.

* Die with an error when the provided Perforce changelist does not exist
* Die with an error if diffs are empty
* Die with an error when there are no changes in a Perforce changelist. Fixes issue 832.
* Default to the default changelist when no Perforce changelist is provided. Fixes issue 1191.

This corresponds to the top four commits at http://github.com/bhollis/rbtools/commits/errorhandling/. Note that 2bd8897b133aa81e2b32 changes the default of running "post-review" in a Perforce client to uploading the default change - the other changes should not introduce any new behavior.
These changes have been in use for a while.
david
  1. I haven't yet looked at the code, but I think your first bullet point is issue 1808.
    1. I just noticed that I'm missing one patch that fixes the "default to default changelist" change - what's there now breaks path-based reviews. I'll add a new diff when I get home that fixes that.
  2. 
      
AJ
  1. Looks good. One small nit, below.
  2. rbtools/postreview.py (Diff revision 1)
     
     
     
     
     
    While the two SHOULD be the same, "\d+ - no such changelist" or just an re.search on "no such changelist" would seem to be more robust and involve less string work.
    
  3. 
      
BH
Review request changed
Change Summary:
Simplify nonexistant changelist detection in response to code review. Also include a missing change that makes defaulting to the "default" Perforce change more robust, and prints the review URL with a trailing slash (to avoid a useless redirect).

I couldn't find on the contributor guide what to do when I've got a "Ship It!" - should I submit a separate pull request on GitHub with a link to this review, or will you pull? Should I squash my commits?
JA
  1. As the reporter of issue 1191, I'd strongly prefer if post-review with no arguments printed a usage summary instead of creating a review request from the default changeset.
    1. But, for all of the other SCMs, like SVN, post-review with no arguments posts a review.
    2. Good point.  I'm not a fan of that behavior (although it makes sense for SVN where there traditionally isn't a changeset to specify), but okay.
      
  2. 
      
david
  1. Thanks for this! I've pushed a squashed version as 65eec92.
  2.