creating multiple review requests for changes in one file
Hi, I am wondering how you handle changes in the same file which don't really fit into the same review request. So you would have a change for which you create a review request. Then you change other things in the same file and would like to create a review request for these changes only. Is it necessary to create branches for each of the changes, wait until the review is complete, commit changes and then merge branches into trunk? Thank, Tino --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "reviewboard" group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~--~~~~--~~--~--~---
Re: creating multiple review requests for changes in one file
Hi Tino, This greatly depends on the revision control system, and isn't really specific to Review Board. If you have separate independent changes you want to post to review, you need to do multiple checkouts or use some sort of a patch-management system (like Quilt). This is a more general issue of how you do development on multiple things at once when dealing with the same files. Christian -- Christian Hammond - chip...@chipx86.com VMware, Inc. On Mon, Dec 29, 2008 at 5:10 PM, Tino Breddin wrote: > > Hi, > > I am wondering how you handle changes in the same file which don't > really fit into the same review request. So you would have a change > for which you create a review request. Then you change other things in > the same file and would like to create a review request for these > changes only. Is it necessary to create branches for each of the > changes, wait until the review is complete, commit changes and then > merge branches into trunk? > > Thank, Tino > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "reviewboard" group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~--~~~~--~~--~--~---
Re: creating multiple review requests for changes in one file
I agree, my question isn't exactly related to reviewboard and I should have been more specific. The vcs in this use-case is Subversion. Having multiple subversion checkouts might be a solution but suffers from a lot of overhead too. Thanks for the hint about the patch- management system Quilt, I'll definitely look into that. I am wondering what "good development practices" evolved out of using Subversion and Review Board. Cheers, Tino On Dec 29, 11:11 pm, "Christian Hammond" wrote: > Hi Tino, > > This greatly depends on the revision control system, and isn't really > specific to Review Board. If you have separate independent changes you want > to post to review, you need to do multiple checkouts or use some sort of a > patch-management system (like Quilt). This is a more general issue of how > you do development on multiple things at once when dealing with the same > files. > > Christian > > -- > Christian Hammond - chip...@chipx86.com > VMware, Inc. > > On Mon, Dec 29, 2008 at 5:10 PM, Tino Breddin > wrote: > > > > > Hi, > > > I am wondering how you handle changes in the same file which don't > > really fit into the same review request. So you would have a change > > for which you create a review request. Then you change other things in > > the same file and would like to create a review request for these > > changes only. Is it necessary to create branches for each of the > > changes, wait until the review is complete, commit changes and then > > merge branches into trunk? > > > Thank, Tino --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "reviewboard" group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~--~~~~--~~--~--~---
Re: creating multiple review requests for changes in one file
Hey Tino, What a lot of us are starting to do both at VMware and within Review Board is to use git as a form of patch management. Git can wrap around both SVN and Perforce, allowing us to do all our work within Git and then push to the proper VCS. My workflow is generally as follows: 1) Create a new topic branch for whatever I'm working on. In git, these are really cheap and easy to create, and you can switch the active topic branch easily, all in one single checkout. 2) Make as many commits as I need until I'm ready to post for review. 3) Make sure my topic branch is branched off of "master" (which should represent HEAD in your VCS, requiring a "rebase" to it if not). 4) Run post-review 5) After approval, squash the branch down to one commit and run "git svn dcommit" to push to Subversion. It seems like there's extra work in there, and there is, but it also makes for a much more flexible environment. I have right now in my one checkout of Review Board some 6 or 7 development branches I'm doing work on. Git definitely has a learning curve, but in my opinion, it's very much worth it. Christian -- Christian Hammond - chip...@chipx86.com VMware, Inc. On Tue, Dec 30, 2008 at 10:22 AM, Tino Breddin wrote: > > I agree, my question isn't exactly related to reviewboard and I should > have been more specific. The vcs in this use-case is Subversion. > Having multiple subversion checkouts might be a solution but suffers > from a lot of overhead too. Thanks for the hint about the patch- > management system Quilt, I'll definitely look into that. > > I am wondering what "good development practices" evolved out of using > Subversion and Review Board. > > Cheers, > Tino > > On Dec 29, 11:11 pm, "Christian Hammond" wrote: > > Hi Tino, > > > > This greatly depends on the revision control system, and isn't really > > specific to Review Board. If you have separate independent changes you > want > > to post to review, you need to do multiple checkouts or use some sort of > a > > patch-management system (like Quilt). This is a more general issue of how > > you do development on multiple things at once when dealing with the same > > files. > > > > Christian > > > > -- > > Christian Hammond - chip...@chipx86.com > > VMware, Inc. > > > > On Mon, Dec 29, 2008 at 5:10 PM, Tino Breddin > > wrote: > > > > > > > > > Hi, > > > > > I am wondering how you handle changes in the same file which don't > > > really fit into the same review request. So you would have a change > > > for which you create a review request. Then you change other things in > > > the same file and would like to create a review request for these > > > changes only. Is it necessary to create branches for each of the > > > changes, wait until the review is complete, commit changes and then > > > merge branches into trunk? > > > > > Thank, Tino > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "reviewboard" group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~--~~~~--~~--~--~---
Re: creating multiple review requests for changes in one file
Hi Christian, Thanks for the detailed explanation of your workflow. I was just looking into using git on the client side too, since I'm familiar with it and patch management is much easier just as you describe. Nevertheless I'd also like to see how other approaches which use subversion instead of git would work. I think having different workflows explained in the documentation on the wiki would greatly help Review Board newcomers to get into it more quickly. Having such a overview certainly helped me to more easily grasp the power and freedom of git. Tino On Tue, Dec 30, 2008 at 1:50 PM, Christian Hammond wrote: > Hey Tino, > > What a lot of us are starting to do both at VMware and within Review Board > is to use git as a form of patch management. Git can wrap around both SVN > and Perforce, allowing us to do all our work within Git and then push to the > proper VCS. > > My workflow is generally as follows: > > 1) Create a new topic branch for whatever I'm working on. In git, these are > really cheap and easy to create, and you can switch the active topic branch > easily, all in one single checkout. > 2) Make as many commits as I need until I'm ready to post for review. > 3) Make sure my topic branch is branched off of "master" (which should > represent HEAD in your VCS, requiring a "rebase" to it if not). > 4) Run post-review > 5) After approval, squash the branch down to one commit and run "git svn > dcommit" to push to Subversion. > > It seems like there's extra work in there, and there is, but it also makes > for a much more flexible environment. I have right now in my one checkout of > Review Board some 6 or 7 development branches I'm doing work on. > > Git definitely has a learning curve, but in my opinion, it's very much > worth it. > > Christian > > -- > Christian Hammond - chip...@chipx86.com > VMware, Inc. > > > > On Tue, Dec 30, 2008 at 10:22 AM, Tino Breddin < > tino.bred...@googlemail.com> wrote: > >> >> I agree, my question isn't exactly related to reviewboard and I should >> have been more specific. The vcs in this use-case is Subversion. >> Having multiple subversion checkouts might be a solution but suffers >> from a lot of overhead too. Thanks for the hint about the patch- >> management system Quilt, I'll definitely look into that. >> >> I am wondering what "good development practices" evolved out of using >> Subversion and Review Board. >> >> Cheers, >> Tino >> >> On Dec 29, 11:11 pm, "Christian Hammond" wrote: >> > Hi Tino, >> > >> > This greatly depends on the revision control system, and isn't really >> > specific to Review Board. If you have separate independent changes you >> want >> > to post to review, you need to do multiple checkouts or use some sort of >> a >> > patch-management system (like Quilt). This is a more general issue of >> how >> > you do development on multiple things at once when dealing with the same >> > files. >> > >> > Christian >> > >> > -- >> > Christian Hammond - chip...@chipx86.com >> > VMware, Inc. >> > >> > On Mon, Dec 29, 2008 at 5:10 PM, Tino Breddin >> > wrote: >> > >> > >> > >> > > Hi, >> > >> > > I am wondering how you handle changes in the same file which don't >> > > really fit into the same review request. So you would have a change >> > > for which you create a review request. Then you change other things in >> > > the same file and would like to create a review request for these >> > > changes only. Is it necessary to create branches for each of the >> > > changes, wait until the review is complete, commit changes and then >> > > merge branches into trunk? >> > >> > > Thank, Tino >> >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "reviewboard" group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~--~~~~--~~--~--~---
Re: creating multiple review requests for changes in one file
Hi Tino, I'm working on user manuals for Review Board, which I'm hoping to finish up for 1.0. Right now, I'm about half way through a detailed Administration Guide. I'll try to keep in mind the workflows suggestion for the Users Guide. It would be interesting to hear from other people on this list about their workflows. Christian -- Christian Hammond - chip...@chipx86.com VMware, Inc. On Tue, Dec 30, 2008 at 3:12 PM, Tino Breddin wrote: > Hi Christian, > Thanks for the detailed explanation of your workflow. I was just looking > into using git on the client side too, since I'm familiar with it and patch > management is much easier just as you describe. > > Nevertheless I'd also like to see how other approaches which use subversion > instead of git would work. > > I think having different workflows explained in the documentation on the > wiki would greatly help Review Board newcomers to get into it more quickly. > Having such a overview certainly helped me to more easily grasp the power > and freedom of git. > > Tino > > > On Tue, Dec 30, 2008 at 1:50 PM, Christian Hammond wrote: > >> Hey Tino, >> >> What a lot of us are starting to do both at VMware and within Review Board >> is to use git as a form of patch management. Git can wrap around both SVN >> and Perforce, allowing us to do all our work within Git and then push to the >> proper VCS. >> >> My workflow is generally as follows: >> >> 1) Create a new topic branch for whatever I'm working on. In git, these >> are really cheap and easy to create, and you can switch the active topic >> branch easily, all in one single checkout. >> 2) Make as many commits as I need until I'm ready to post for review. >> 3) Make sure my topic branch is branched off of "master" (which should >> represent HEAD in your VCS, requiring a "rebase" to it if not). >> 4) Run post-review >> 5) After approval, squash the branch down to one commit and run "git svn >> dcommit" to push to Subversion. >> >> It seems like there's extra work in there, and there is, but it also makes >> for a much more flexible environment. I have right now in my one checkout of >> Review Board some 6 or 7 development branches I'm doing work on. >> >> Git definitely has a learning curve, but in my opinion, it's very much >> worth it. >> >> Christian >> >> -- >> Christian Hammond - chip...@chipx86.com >> VMware, Inc. >> >> >> >> On Tue, Dec 30, 2008 at 10:22 AM, Tino Breddin < >> tino.bred...@googlemail.com> wrote: >> >>> >>> I agree, my question isn't exactly related to reviewboard and I should >>> have been more specific. The vcs in this use-case is Subversion. >>> Having multiple subversion checkouts might be a solution but suffers >>> from a lot of overhead too. Thanks for the hint about the patch- >>> management system Quilt, I'll definitely look into that. >>> >>> I am wondering what "good development practices" evolved out of using >>> Subversion and Review Board. >>> >>> Cheers, >>> Tino >>> >>> On Dec 29, 11:11 pm, "Christian Hammond" wrote: >>> > Hi Tino, >>> > >>> > This greatly depends on the revision control system, and isn't really >>> > specific to Review Board. If you have separate independent changes you >>> want >>> > to post to review, you need to do multiple checkouts or use some sort >>> of a >>> > patch-management system (like Quilt). This is a more general issue of >>> how >>> > you do development on multiple things at once when dealing with the >>> same >>> > files. >>> > >>> > Christian >>> > >>> > -- >>> > Christian Hammond - chip...@chipx86.com >>> > VMware, Inc. >>> > >>> > On Mon, Dec 29, 2008 at 5:10 PM, Tino Breddin >>> > wrote: >>> > >>> > >>> > >>> > > Hi, >>> > >>> > > I am wondering how you handle changes in the same file which don't >>> > > really fit into the same review request. So you would have a change >>> > > for which you create a review request. Then you change other things >>> in >>> > > the same file and would like to create a review request for these >>> > > changes only. Is it necessary to create branches for each of the >>> > > changes, wait until the review is complete, commit changes and then >>> > > merge branches into trunk? >>> > >>> > > Thank, Tino >>> >>> >> >> >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "reviewboard" group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~--~~~~--~~--~--~---
Re: creating multiple review requests for changes in one file
> It would be interesting to hear from other people on this list about their > workflows. I use svn here and for the most part I just work away on multiple changes in a single workspace. When I finish a particular part, I'll post a review for only those files. Once the review is done, I commit only those files and continue my changes. Another approach I was considering is to check out a new project when working on something that does not require changes in my current workspace. This will make creating patches easier and let me focus on the task at hand (instead of having other changes get in the way). We do most of our reviews by applying the patch to a fresh project to catch any missing files or other compile errors. It also lets us use our IDE to better understand and go over changes. I like the idea of using Git, it's a good suggestion. -- Arthur Kalmenson On Tue, Dec 30, 2008 at 6:35 PM, Christian Hammond wrote: > Hi Tino, > > I'm working on user manuals for Review Board, which I'm hoping to finish up > for 1.0. Right now, I'm about half way through a detailed Administration > Guide. I'll try to keep in mind the workflows suggestion for the Users > Guide. > > It would be interesting to hear from other people on this list about their > workflows. > > Christian > > -- > Christian Hammond - chip...@chipx86.com > VMware, Inc. > > > On Tue, Dec 30, 2008 at 3:12 PM, Tino Breddin > wrote: >> >> Hi Christian, >> Thanks for the detailed explanation of your workflow. I was just looking >> into using git on the client side too, since I'm familiar with it and patch >> management is much easier just as you describe. >> Nevertheless I'd also like to see how other approaches which use >> subversion instead of git would work. >> I think having different workflows explained in the documentation on the >> wiki would greatly help Review Board newcomers to get into it more quickly. >> Having such a overview certainly helped me to more easily grasp the power >> and freedom of git. >> Tino >> >> On Tue, Dec 30, 2008 at 1:50 PM, Christian Hammond >> wrote: >>> >>> Hey Tino, >>> >>> What a lot of us are starting to do both at VMware and within Review >>> Board is to use git as a form of patch management. Git can wrap around both >>> SVN and Perforce, allowing us to do all our work within Git and then push to >>> the proper VCS. >>> >>> My workflow is generally as follows: >>> >>> 1) Create a new topic branch for whatever I'm working on. In git, these >>> are really cheap and easy to create, and you can switch the active topic >>> branch easily, all in one single checkout. >>> 2) Make as many commits as I need until I'm ready to post for review. >>> 3) Make sure my topic branch is branched off of "master" (which should >>> represent HEAD in your VCS, requiring a "rebase" to it if not). >>> 4) Run post-review >>> 5) After approval, squash the branch down to one commit and run "git svn >>> dcommit" to push to Subversion. >>> >>> It seems like there's extra work in there, and there is, but it also >>> makes for a much more flexible environment. I have right now in my one >>> checkout of Review Board some 6 or 7 development branches I'm doing work on. >>> >>> Git definitely has a learning curve, but in my opinion, it's very much >>> worth it. >>> >>> Christian >>> >>> -- >>> Christian Hammond - chip...@chipx86.com >>> VMware, Inc. >>> >>> >>> On Tue, Dec 30, 2008 at 10:22 AM, Tino Breddin >>> wrote: I agree, my question isn't exactly related to reviewboard and I should have been more specific. The vcs in this use-case is Subversion. Having multiple subversion checkouts might be a solution but suffers from a lot of overhead too. Thanks for the hint about the patch- management system Quilt, I'll definitely look into that. I am wondering what "good development practices" evolved out of using Subversion and Review Board. Cheers, Tino On Dec 29, 11:11 pm, "Christian Hammond" wrote: > Hi Tino, > > This greatly depends on the revision control system, and isn't really > specific to Review Board. If you have separate independent changes you > want > to post to review, you need to do multiple checkouts or use some sort > of a > patch-management system (like Quilt). This is a more general issue of > how > you do development on multiple things at once when dealing with the > same > files. > > Christian > > -- > Christian Hammond - chip...@chipx86.com > VMware, Inc. > > On Mon, Dec 29, 2008 at 5:10 PM, Tino Breddin > wrote: > > > > > Hi, > > > I am wondering how you handle changes in the same file which don't > > really fit into the same review request. So you would have a change > > for which you create a review request. Then you change other things > > in > > the same file and would like to create a review
