[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN with code review workflow

From: Ryan Schmidt <subversion-2009b_at_ryandesign.com>
Date: Mon, 29 Jun 2009 21:55:47 -0500

On Jun 29, 2009, at 10:38, Brian FitzGerald wrote:

> One solution I have heard of large shops using is to have each
> developer have their own branch in the repository, so that once their
> coding is complete, they would commit to their personal branch. Then,
> the code reviewer would perform a commit from the developers branch to
> the (and I get hazy about the specifics here) main development branch
> (would this need to be a separate repository?).

My case against a branch per developer is that there's no reason why
a developer would be working on only one task. I was usually working
on several tasks for each project, at the last web development
company where I worked. I didn't use separate branches, but I did use
multiple working copies of each project's trunk. But then we didn't
have restrictions on who could commit to trunk. Once I was done
working on one task I could commit it and move to another one. If,
after finishing a task, I had to send it off to someone for a lengthy
approval process, I wouldn't want to have to sit around waiting for
their response. I'd want to be able to work on a new task, which
should then be in a different branch to not muck up the reviewers.
Hence a branch per feature as already suggested.

I also wanted to point out there's no reason why you can't continue
to do exactly what you do now, only with Subversion. Set up a
repository but only give commit access to your reviewers. The
developers continue to develop and send patches or whatever to the
reviewers, and only they would commit it, once they've reviewed it.
I'm not saying this is a great way to set up Subversion, but it is a
way to use it that would not differ much from what you do now, thus
might be easier to get approved by the powers that be. Then once
that's in place, you can start suggesting small ways the workflow can
be changed to make it more better, e.g. showing how allowing commit
access to non-reviewers to non-trunk areas like branches would allow
developers to be more productive while not impacting your review
mechanism for trunk.


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-30 04:57:13 CEST

This is an archived mail posted to the Subversion Users mailing list.