The typical way that other dvcs users do this is to have local branches for 
each piece of work, and post from each of those. I don't know enough about 
bzr's workflow to know if that would be appropriate (though I recall bzr 
branches being pretty heavyweight).

-David

> On Feb 15, 2014, at 12:51 PM, Charles Yates <charles.ya...@gmail.com> wrote:
> 
> Hi,
> 
> We're trying to follow a pre-commit workflow with bzr with all patches 
> submitted to the review board prior to checkin to the repo - I was wondering 
> anyone had any experience with this and how best to handle pending patches. 
> 
> Sometimes it's inconvenient to wait for the review process to be completed 
> before working on another part of the code - as a result, I can have a few 
> patches pending and cherry picking the right files from the checkout to 
> manually create a diff can be quite time consuming and error prone when there 
> are a handful of small review posts pending. 
> 
> I've written a quick and dirty script which associates specific files with a 
> review ticket and provides me with a view of changes which have been made on 
> those files since the last posting - it also allows the files included to be 
> manipulated from the command line and post the current patches as required. 
> I'm quite sure it can be improved upon and would be happy to provide a link 
> to it if anyone is curious (or just wants to point and laugh :p). 
> 
> I was wondering if there were other ways to handle this - I was vaguely 
> thinking about using some kind of local repo, tagging each checkin comment 
> with the associated review id and creating review posts from that, but it 
> would still involve some kind of manual cherry picking process when handling 
> merges from other developers. With the tool I have, the latter tends to be a 
> bit of a non-issue as I just need to make the corrections, and run my script 
> against each of my pending reviews and it does the rest (with the exception 
> of patches which pending patches which touch the same source files - those 
> tend to block me until the previous review is cleared up).
> 
> Possibly over thinking the issue :-) - any suggestions welcome.
> 
> Cheers,
> 
> Charlie
> -- 
> 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.

-- 
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