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 For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en To unsubscribe, reply using "remove me" as the subject.