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


Christian Hammond - chip...@chipx86.com
VMware, Inc.

On Tue, Dec 30, 2008 at 10:22 AM, Tino Breddin

> 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" <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
> 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
> > <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 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 
For more options, visit this group at 

Reply via email to