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:

post <id>

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 
for example).

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 
"reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to