Hi Christian Thank you very much for the detailed reply, it helped immensely in figuring out how our process should work!
I have implemented this now via the *.reviewboardrc* file combined with a batch file. Just for interests sake, here is the batch file I made, Thanks again! @echo off setlocal rem == ================================================= rem @author Willie Scholtz rem @createdDate 2015-10-01 rem Posts or updates a review on the review board server rem == ================================================= rem check id rbt is installed where rbt > nul 2> nul if %errorlevel% neq 0 goto :installRbt goto :main :installRbt echo RBT is not installed on this system, please install it! goto :end :main rem check if we should update or post a new review set /p _revNum=Enter review number to update, or leave empty for new review: if "%_revNum%" == "" goto:newReview goto :updateReview :updateReview echo updating review with #%_revNum% rbt post -r %_revNum% goto :end :newReview set /p _summary=Enter the summary for this ticket: set /p _bugs=Enter a comma separated list of bugs that this ticket addresses: if ["%_summary%"] == [] goto :noSummary echo ============================== echo Submitting new review request: echo ------------------------------ echo Summary : %_summary% echo Bugs Closed: %_bugs% echo ============================== rbt post --open --markdown --bugs-closed "%_bugs%" --summary "%_summary%" goto :end :noSummary echo Please enter a valid summary! goto :end :end On Monday, 28 September 2015 21:20:46 UTC+2, Christian Hammond wrote: > > Hi Willie, > > The expectation is that if you're doing a post-commit workflow like this, > where you commit and then post for review, you're not going to reuse the > same review request. > > A review request is intended to handle the review of a single change and > all is iterations. When you post something for review, you create a review > request, get feedback, and then you're expected to iterate on *that* change > (not a new one), containing both the original code and the fixes made, so > that reviewers can see the whole complete state of your change. > > What you're currently doing is posting one change for review (a change > that's already committed), and then creating new changes that don't in any > way contain the original change as new commits, but wanting both to appear > in a review request. This ends up causing the following issues: > > 1) You lose out on the ability to do interdiffs (which are used to see and > comment on the differences between any two iterations of your change). > > 2) It's letting code that may have errors go into the codebase, > potentially impacting others unnecessarily, rather than committing only > fully-reviewed, safe code. > > 3) It makes it far harder to track cohesive changes when going back > through the codebase or review request history. > > What we recommend is a pre-commit model. In this model, you would change > your steps to: > > 1) Modify code, but don't commit. > 2) Developer runs `rbt post` > 3) Reviews happen, and the developer gets feedback. > 4) Developer modifies the code in their tree. Still doesn't commit. > 5) Developer runs `rbt post -r <ID>` to update the change. > 6) Rinse and repeat until the change is ready to commit. > > This will give you all the intended power of our review requests and > interdiffs, and will prevent your repository from containing half-baked > changes that may end up blocking other developers. > > Christian > > -- > Christian Hammond - [email protected] <javascript:> > Review Board - https://www.reviewboard.org > Beanbag, Inc. - https://www.beanbaginc.com > > On Mon, Sep 28, 2015 at 6:42 AM, Willie Scholtz <[email protected] > <javascript:>> wrote: > >> Hi There >> >> I finally managed to install and get reviewboard running, >> >> Our team has about 9 developers who all use windows machines, we have a >> Subversion repository. >> >> I helped everyone setting up "rbt" and currently our workflow >> (post-commit) works like this: >> >> >> - commit code to */trunk* >> - developer runs *rbt post REV_NUMBER -> creates review #* >> - review group receives mail and starts review >> - finds issues, and creates review >> - submitter receives mail and fixes code, commit to trunk >> - developer runs rbt post -r <review_id> REV_NUMBER >> - cycle continues... >> >> >> This works awesome, except that I have run into two problems, but this >> may be a config issue, or something we are doing wrong. >> >> >> - When submitting via "rbt post", the "Change" field does not get >> populated? >> >> >> - this works when going through the web-front end: >> 1. >> >> Change:9947 >> >> >> >> >> >> - when updating requests via "rbt post -r <review_id> REV_NUMBER", >> the diff slider behaves very strange >> - for instance when sliding between ORIG, and subsequent updates, >> it detects that in updates, origin files have been deleted. >> - ex: >> - commit 1 has file 1, 2 and 3 >> - commit 2 updates file 2 >> - the review slider between ORIG and 2 will be the update on file >> 2, and it will show file 1 and 3 as deleted, this is very confusing to >> the >> reviewers >> >> >> Thanks for taking the time to help, I have read the manual a few times >> and googled a lot, but I can't seem to find the answer, any help would be >> appreciated :) >> >> -- >> Supercharge your Review Board with Power Pack: >> https://www.reviewboard.org/powerpack/ >> Want us to host Review Board for you? Check out RBCommons: >> https://rbcommons.com/ >> Happy user? Let us know! https://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 [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/ Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/ Happy user? Let us know! https://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 [email protected]. For more options, visit https://groups.google.com/d/optout.
