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 - chip...@chipx86.com
Review Board - https://www.reviewboard.org
Beanbag, Inc. - https://www.beanbaginc.com

On Mon, Sep 28, 2015 at 6:42 AM, Willie Scholtz <williescho...@gmail.com>
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+unsubscr...@googlegroups.com.
> 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