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 - chi...@chipx86.com <javascript:>
> Review Board - https://www.reviewboard.org
> Beanbag, Inc. - https://www.beanbaginc.com
>
> On Mon, Sep 28, 2015 at 6:42 AM, Willie Scholtz <willie...@gmail.com 
> <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 reviewboard...@googlegroups.com <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 reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to