> So with this process, you want to continually
> update an existing review request, and you want it to incorporate the new
> updates alongside the existing ones? So if it's already created with a diff
> modifying 5 files, the next update that adds 2 files will result in a diff
> containing a total of 7?

Yep! Exactly.

> So that won't happen today unless that revision range spans the revision
> originally modifying those 5.

Right.  I'm getting around this by automatically publishing the review
when it gets created or updated.  That seems to be working, and I'm
actually happy about the way that works.  Since I'm writing the plugin
for Hudson, when a build runs, it creates or updates a review request
and then publishes it.  This way the review request emails get sent
out and the author knows when it's been done.  Otherwise they wouldn't
know to go into RB and manually publish it.  So, I'm ok with this
process currently and think that in an automated process like what I'm
doing, updating a diff with new files would defeat the purpose of
automation because it would still require a manual step that I want to

> Going to be working toward expanding RBTools to make it easier to write 
> custom scripts such as
> this, so maybe it'd be better there?

Yeah, I'd agree.  I know you're currently developing some APIs and
hooks, but in the interim I've developed a Java API that calls your
RESTful endpoints with the proper params and authentication to update
fields and publish reviews.  Works fine for me for the moment.

Thanks for following back up!


Want to help the Review Board project? Donate today at 
Happy user? Let us know at http://www.reviewboard.org/users/
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to