Re: Subversion workflow help
Hi, I can see this is old post, but this post is most similar to my problem, so I will just join this discussion. I hope it's ok. In my company, we use SVN, and we installed RB in order to improve quality of our code. I tried to use RB with pre-commit review workflow but it seems that it don't fit our needs. Our commits includes small chunks of code, and we commit very often. Also, very often commits use same files (eg. we have RIA Service Domain class with a lot of business logic in it). Because of that, with pre-commit workflow if developer create review which includes file1 and he have other change in same file1 waiting to be implemented, he cannot continue working until first review process is over. If he continues before that happens, next review will include first change and second change, in same review request. The reviewer have to spend too much time to filter only change 2. And this is simplified version of that problem. So, we decided to try with post-commit workflow, and there is next problem: We cannot iterate on same original change. If something have to be fixed, developer only have option to mark review as "Fixed" and if he wants to update original change in that review that is not an option. Instead, he have to open new review requests to iterate same change, but then we have all same problems Willy had. Can You give me solution for our problems, no matter if it is pre or post commit? Thanks a lot. On Monday, September 28, 2015 at 9:20:46 PM 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 ` 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 > Review Board - https://www.reviewboard.org > Beanbag, Inc. - https://www.beanbaginc.com > > On Mon, Sep 28, 2015 at 6:42 AM, Willie Scholtz > 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 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 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 >>
Re: Subversion workflow help
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 ` 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 > Review Board - https://www.reviewboard.org > Beanbag, Inc. - https://www.beanbaginc.com > > On Mon, Sep 28, 2015 at 6:42 AM, Willie Scholtz > 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 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 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. >> - e
Re: Subversion workflow help
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 ` 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 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 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 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.
Subversion workflow help
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 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 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.
