On Monday, October 31, 2011 10:45:15 AM UTC-4, Stephen Gallagher wrote: > I've been trying to work out for some time now how to accomplish > patch-series in Git with Review Board. This is a very important part of > my project's workflow, and the lack of this support has been preventing > us from deploying.
Patch series was the one feature missing from RB that my team really wanted. We ended up integrating topic branches into our workflow as a surrogate for patch series and use a custom script to create reviews (currently running RB 1.6.12). In our current workflow, there are two ways reviews are generated: 1) commits on "main" branches (e.g. master or maint) automatically generate a review via a post-receive hook 2) The topic-branch-review script, a wrapper around post-review, which a developer runs when s/he is ready to merge (essentially a pull request) topic-branch-review is pretty easy to use: topic-branch-review topic-branch base-branch [-r=reviewID --last-reviewed=first_diff] Internally the script calculates the merge base of topic and base. It then iterates over commits between the topic-branch and the merge-base, calculating the diff between each commit and the merge-base (not the commit's parent). Doing cumulative diffs allows us to use the interdiff functionality in RB to see one or more commits (many of our devs like seeing the topic branch as a single commit for review, I tend to break it down into a patch series). Each diff is used to update the original review, with a change description set to the oneline commit summary. The review request summary is simply the log of all the commits uploaded (the developer can use this as a starting point when adding a real description). The optional arguments are to update an existing review (usually in response to review comments), and follows the same cumulative diff methodology. The script is simple enough we try not to deal with rebases or merges. Common practice is to rebase the topic branch on top of the base branch just prior to posting the review, but then not rebase after that. I know we have dealt with merging the base branch into the topic branch, but I forget the details now (I think it shows up as a single commit with all the changes from the base). >From personal experience, I'd say this model works well for new features that require 10-30 commits to achieve maturity. We've reviewed some 70-100 commit topic branches, which I generally don't recommend but certainly happens. With that many commits remembering what RB diff number goes with which commit is almost impossible -- this could be improved with some UI in RB that helps translate diff number to commit ID (or change description). With the script we've found RB fits our development style very well and is very comfortable for our (relatively informal) review workflow. I hope this information is useful. Thanks, Stephen -- 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