[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: Les Mikesell <lesmikesell_at_gmail.com>
Date: Mon, 29 Jun 2009 11:22:14 -0500

Brian FitzGerald wrote:
>
> 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.

Just because someone commits a change to the trunk doesn't mean you have to use
it in production.

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

Unless you expect the developers' changes to be disruptive (refactoring,
renaming many files, changing interfaces, etc.) isolating developers is likely
to be counterproductive. Instead you can just recognize that the trunk is where
development happens and the head view won't always be perfect. Just don't build
your production release from trunk/head.

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

While big changes are being made, this can happen directly in the trunk. When
you are close to a release, branch for the release and do final tuning there
applying whatever quality control approaches you want. That might include code
review and builds with performance tests, perhaps with a limited number of
people allowed to make changes. And, you'd probably make tag copies to identify
each of these changes up through the final one.

-- 
    Les Mikesell
     lesmikesell_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2366447
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-29 18:23:19 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.