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

Re: Subversion + Review Workflow

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 23 Jun 2008 19:06:50 +0200

On Mon, Jun 23, 2008 at 05:41:16PM +0200, luckyluke2k wrote:
> Is it possible to configurate a gatekeeper in subversion? The source
> code should be reviewed, before a developer can submit it in the
> repository.

Not allowing people to commit even though they might want to do so
is almost always a really bad idea. It prevents people from
checkpointing their work, and it prevents others from seeing
what they are currently working on.

> Or is it only possible to generate two branches? A branch as
> a developing branch and a branch as a distribution branch.

I would recommend this approach.

Using a separate branch for development is an approach we also
use to develop Subversion itself. In our case, your "distribution
branch" is our "trunk". In all examples below, you can mentally
replace "/trunk" with "/distribution" or any other name you like.

When one or more developers work on a new major feature, they create
a branch for it and do development there:

 svn copy http://svn.example.com/repos/trunk \
   http://svn.example.com/repos/branches/feature-branch \
   -m "Create a new feature branch to work on an exciting feature."
 svn checkout http://svn.example.com/repos/branches/feature-branch
 cd feature-branch
 <start hacking>

While working on the branch, they regularly sync their branch with
trunk to keep up-to-date with latest code changes made there.
In Subversion 1.5, all you need to do for that is to go into a
working copy of your branch and run:

 svn merge http://svn.example.com/repos/trunk
 <compile, run tests>
 svn commit -m "Merge outstanding changes from trunk."

Once the branch has reached maturity (or at any other convenient point
in time), they ask other people to review the changes they made on the
branch. You can easily see all the changes made on the branch. All you
need to know for that is the revision in which the branch was last synced
with trunk. If that revision was, say, 424242, the command would be:

 svn diff http://svn.example.com/repos/trunk@424242 \
This should give you a clean diff showing only what has changed
on the feature branch with respect to trunk.

Other people can also easily check out the branch to build
and test it locally.

When the work done on the branch is considered complete, you can merge
it into trunk by checking out a working copy of trunk and doing
a "reintegrate" merge:

 svn checkout http://svn.example.com/repos/trunk
 cd trunk
 svn merge --reintegrate http://svn.example.com/repos/branches/feature-branch
 <compile, run tests>
 svn commit -m "Merge feature branch into trunk"

Note that the above is only possible as of 1.5. With 1.4, things are
more complicated, but I won't go into that -- you really should upgrade
to 1.5 anyway.

Then you can dispose of the branch, to indicate that it is no longer
actively being used:

 svn rm http://svn.example.com/repos/branches/feature-branch \
     -m "Remove feature-branch, it has been merged into trunk."

You can see how we use branches like this by browsing our repository:

See also http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html

Hope this helps,

  • application/pgp-signature attachment: stored
Received on 2008-06-23 19:07:17 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.