Hi Ryan,

Been out of town the past few days, so I'm catching up on e-mail now.

Okay, so I think I understand. 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?

So that won't happen today unless that revision range spans the revision
originally modifying those 5. If you post a review request with a range that
covers one set of files, and then update it with a diff covering another set
of files, then the latest diff will only contain that second set. The first
set will still exist as a revision, but won't be the latest shown.

It might be possible to come up with something a bit more custom to augment
the existing diff, but I don't know how clean it would be right now. You'd
have to download the existing diff, figure out what should be
removed/appended/replaced, and update that.

I don't think augmenting the latest diff is a very common scenario. If it
turned out to be easy (unlikely without the new APIs I'm doing for 1.5 and
without parsing the downloadable diff file) then maybe we could add it to
post-review, but it might be best as its own tool. 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?

Please let me know if I misunderstood.


Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com

On Tue, Mar 30, 2010 at 3:30 PM, rshelley <ryan.shel...@disney.com> wrote:

> Ok, let me clarify with a concrete scenario.
> We use JIRA for our bug tracking.  JIRA generates bug IDs such as
> "BUG-123".  We also have Hudson for continuous integration, and it's
> tied to Perforce to poll for changes, build the changes, and log the
> changelists in the build (for release notes).  Our standard process is
> to include within our Perforce descriptions the JIRA bug ID our check-
> in is for, so Perforce syncs with JIRA to update the issue with the
> Perforce files modified to complete the circle.  So now we know what
> files were changed to fix what bugs in which build (and in reverse,
> what build certain changes were included in by reference through
> JIRA).
> There are many, many, MANY times where one check-in (and therefore,
> one changelist) does not encompass all of the changes required to
> resolve the bug, but all changes are tracked by a single JIRA.  We
> have a culture of checking-in often and not holding onto files for
> days on end until we check-in one massive changelist since we're
> developing in a highly collaborative and volatile environment (we
> often have people developing within the same file at the same time, so
> merges are often done on a daily basis).  This is why we use CI to
> build and test the project regularly.  So it doesn't make sense for us
> to create dozens of new review requests for new changelists since they
> are often updates to a related JIRA.
> Now, we're both in agreement that the CLI provides all the
> functionality of creating and updating reviews and the developer can
> decide what files update what reviews and when to create a new
> review.  However, I can't get my developers to use it.  Both Kyle
> Hayes and I have been expounding it, documenting it internally,
> emailing our team, and we haven't had a single person use it yet.  And
> until I have something people will use (or even better, in their view,
> is if it's done for them), I can't make it a standard.
> So my goal is to create a Hudson plugin to link Perforce and
> Reviewboard for post-commit reviews.  Now, I know that Reviewboard has
> a field for Bugs, which we currently have linked to JIRA, but I'm not
> aware of a way to pass that in as part of post-review, or retrieve
> through a CLI query, so I'm looking into mapping a Perforce
> changelist, to a JIRA bug (via the bug ID entered in the changelist
> description) and the Reviewboard ID.  This mapping should be
> relatively trivial.  What isn't trivial is making updates to a review
> request when an updated changelist is submit (meaning a second
> changelist is submit with the same JIRA bug ID as another changelist
> that has an open review request).  This is where my Improvement
> request 1562 would have been helpful.
> From what I gather in your post, however, is that "revision-range"
> isn't supported by post-review for Perforce which shouldn't be a
> problem.  Hudson gives me the depot paths as part of the change set
> the build was executed for.  I just want to make sure that if I have 5
> files in the review, and I add 2 and update 3 that the review shows 7
> files with three deltas and the other 3 files that were in the
> original review aren't dropped.
> I hope that makes sense and isn't too confusing.  I know post-commit
> is a less-than-ideal solution.  I'm pro-pre-commit, but my team is
> not.  Well, they're not even really pro-review, but that's going to
> change, and I need to start somewhere.  So, unless I make it easy or
> transparent to them, they will keep pushing back.  For the time-being,
> some review is better than no review!
> --
> Want to help the Review Board project? Donate today at
> http://www.reviewboard.org/donate/
> Happy user? Let us know at http://www.reviewboard.org/users/
> -~----------~----~----~----~------~----~------~--~---
> To unsubscribe from this group, send email to
> reviewboard+unsubscr...@googlegroups.com<reviewboard%2bunsubscr...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/reviewboard?hl=en
> To unsubscribe, reply using "remove me" as the subject.

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