[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: Carsten Koch <CarstenKochICEM_at_web.de>
Date: Mon, 29 Jun 2009 20:16:37 +0200

On Mon, 2009-06-29 at 11:38 -0400, 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?).

We have a combination of policies,
configurations, hooks scripts and python tools
to enforce the following workflow:

Each software product we develop has its own repository
http://svn/product_name

Each repository has a main development line
http://svn/product_name/trunk

some older branches
http://svn/product_name/branches/branch_name

a collections of official builds
http://svn/product_name/builds/build_name

and a collection of modification branches
http://svn/product_name/mods/branch_name

The commit rights in the repository are restricted,
so only very few people (and robots) can commit
everywhere and all developers can commit into
http://svn/product_name/mods/

Whenever a developer starts a modification, they create
a branch which can be a copy of the head revision of
the trunk or older branch or of a specific official build.
As a convention, developer bob calls a branch that is
created to fix issue #4711
http://svn/product_name/mods/bob-issue_4711

We have a "create_mod" GUI tool that automates this.

bob now has his own private branch that will not
change unless he commits a change to it.

When bob is done with his modification, he can use
a tool to build it on all platforms and another tool
that re-merges it so it fits into the head or the
latest build.
Once bob is satisfied with his mod branch, he submits
it for code review to one to five other developers
using a "submit_mod" GUI tool.
(These tools use svn properties to keep track of the
mod state)
Once all developers have accepted the mod, a daemon
picks it up, builds it on all platforms and commits
it back into the trunk or the older branch where it
originated if the build was OK on all platforms.

We currently have about a dozen svn repositories that
are managed this way and form a hierarchy of software
products that re-use some base products (libraries)
to build end products based on them.

During the night another daemon works its way through this
hierarchy (of 30 trunks / older branches) and creates
the official builds.

Carsten.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2366489

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-29 20:20:42 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.