[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: <russ_at_vshift.com>
Date: Mon, 29 Jun 2009 15:56:31 +0000

I wouldn't recommend a developer's branch personally. I would have a branch per feature/change request/ticket and once that's complete, it can go to the reviewer to review and merge into trunk.

This is what we do for larger changes, with the branches corresponding to their trac ticket numbers.

Having a single developer branch would force the developer to stop working - or at least not commit his changes until the review of the previous change has been made and approved.

Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Brian FitzGerald <bmfitzgerald3_at_gmail.com>

Date: Mon, 29 Jun 2009 11:38:19
To: <users_at_subversion.tigris.org>
Subject: SVN with code review workflow

Greetings all,

I am a Web developer with a company who (rightfully so) places a large
amount of importance on code review. For this reason, up to this
point, they have not implemented a traditional version control system,
such as Subversion.

The concern of certain key people in the organization is that putting
SVN in place would mean losing control of the code base in that
developers could simply commit whatever, whenever they wanted, without
going through the highly valued code review process.

I understand their concern, and I have a few ideas about what could be
some potential solutions to our problem, but I wanted to get thoughts
from others about ways they have seen this tackled.

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?).

At this point, the code reviewer could look at all the diffs between
the code in the developers branch, and the code in the main
development branch, and either reject or approve and commit the code.
For updates, developers would grab from the main development
repository (or branch), so that they would always be synced up with
the changes committed (and approved) by other developers.

I have also heard of tools such as Codestriker
which apparently integrate with SVN and may be valuable in this
process as well.

What solutions have you all seen in action? Thanks in advance for any
other thoughts on the topic.


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-29 17:57:43 CEST

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