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
It would be interesting to hear from other people on this list about their
Christian Hammond - chip...@chipx86.com
On Tue, Dec 30, 2008 at 3:12 PM, Tino Breddin
> 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.
> On Tue, Dec 30, 2008 at 1:50 PM, Christian Hammond <chip...@chipx86.com>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 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.
>>> On Dec 29, 11:11 pm, "Christian Hammond" <chip...@chipx86.com> 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
>>> > 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
>>> > you do development on multiple things at once when dealing with the
>>> > files.
>>> > Christian
>>> > --
>>> > Christian Hammond - chip...@chipx86.com
>>> > VMware, Inc.
>>> > On Mon, Dec 29, 2008 at 5:10 PM, Tino Breddin
>>> > <tino.bred...@googlemail.com>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
>>> > > 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
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to
For more options, visit this group at