On Wednesday, 19 February 2014 16:36:21 UTC+1, Allen wrote:
> Really good question!
> I also encounter the same problem. Developers dont want to wait until the
> previous review passed to work on the next issue.
> One solution I think is, once a review passed, apply that review`s patch
> file to a new working copy without touching what you are currently working
> on, then commit it. After the commit is done, you can keep going.
With the script I use, I tend to work with a single checkout. There's a
little bit of manual cherry picking when I initially create the first
reviewboard post, but subsequently, it remembers which files are associated
to the <id>, so the workflow goes something like:
* I create a new reviewboard entry via the website (I find this easier for
adding detailed descriptions, test information and assigning to another
* After that point, I use the script to create and upload the diff like:
post <id> --new file1 file2 ..
or entire subdirectories or other file patterns (non specification of files
takes all currently modified files). This uploads the current diffs in
those files to the review id (there's also a --publish switch but I tend to
do a sanity check in the browser to check on whitespace, mismatching
indents and so on).
* Once done, and pre-review, I start working on the another patch and
repeat the process - cherry picking the files which are involved in that
review (this essentially disallows subsequent jobs from overlapping with
the files in the first review, though there is an attempt to provide some
support for that - typically, I see such tasks as blocking ones and insist
on the prior review being carried out first).
* During the review process, I tend to make the modifications for the id's
as per the review of my colleague, and run:
after making the suggested modifications - this just uploads the revised
patch for the files associated to that review id (being a no-op if no
subsequent changes have occurred).
* At the point of checkin, I tend to use:
bzr ci -m "blah" `post <id> --list`
And this commits the changes for that id, leaving everything else alone.
There are few other odds and ends in the script (and scripts which use that
one :)) which assist in associating (and disassociating) files from reviews
and that provide a view of changes since the last post (post <id> --diff
None of it's ideal as it's not entirely automated (and the overlapping file
restrictions kinda hurts), but it works fairly well and at the very least
doesn't need me to cherry pick the file list on every subsequent post,
diff, checkin etc.
> But the pinpoint is, when you create a code review, the paths in the patch
> file is NOT your local path but some paths in the SVN server(I am using
> SVN). That prevents me to apply patches(wrong patch error).
> I have no idea why the review board changes the paths from local to remote
> server, at least it should keep the local working copy`s path.
> Here`s a example of what those paths look like:
> --- /trunk/ReviewBoardTest/src/ReviewBoardTest.java (revision 166)
> +++ /trunk/ReviewBoardTest/src/ReviewBoardTest.java (working copy) you
> see here? The working copy is locally, but the review board still changes its
> path to remote server.
Ah - that's interesting - I tend to pull other developers patches from the
reviewboard when I'm reviewing them using:
rbt patch <id> --print | patch -p0
and those apply to my checkouts correctly (assuming compatible branches and
lack of conflicts in local mods). I tend to use a second checkout when
reviewing the work of others, and resolve conflicts in my own main checkout
after those have been committed (invoking post <id> for each of my pending
The pulled patches don't have the branch reflected in the paths though -
guess this could be an svn specific thing? Perhaps patch -p1 would resolve
that specific issue for you?
Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/
Sign up for Review Board hosting at RBCommons: https://rbcommons.com/
Happy user? Let us know at http://www.reviewboard.org/users/
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.