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

Re: Peer-reviewed commits (design ideas)

From: Bruce Atherton <bruce_at_callenish.com>
Date: 2002-02-12 01:54:38 CET

At 09:19 PM 2/9/2002 -0800, Sean Russell wrote:
>I've got two basic systems, with one variation. Each has its advantages.
>I'll outline them briefly.
>== Branch controlled reviews
>1) Each developer has their own branch.
>2) When a developer finishes a "task", they commit and make a note of the
>version. The rational/reasoning for the commit goes in the log file.
>3) The other developers are alerted to this commit. This can happen in a
>number of ways, such as a COMMITS file in the main branch, with
>developer/version pairs, or via email. Whatever.
>4) At lesiure, the other developers pull a commit out of the queue and do a
>diff on the main branch vs. that commit, and review the commit.
>5) They yea or nay it, request information, whatever.
>6) When it finally gets enough "yeas", the originaly developer merges that
>commit into the main trunk.

I've been thinking for a while that this system is the right way to go
since it is so easy for everyone to integrate into their own varied systems
once branches become cheap.

I have two points on your design, though. The first is that
branch-per-developer is only one way to do it, and probably not the best
for your situation considering that what you want is broken down into
"tasks". How about branch per changeset? You could name branches after
issue numbers in your bug tracking software, or allow any developer to
freely create any branches they wanted, with the understanding that it
doesn't get into the trunk without approval.

Branching by task rather than developer allows developers to work on
several tasks in isolation, and also allows groups of programmers to work
on the same set of changes in a coordinated way.

>I like this system for a couple of reasons. We can do it now (well, as soon
>as merging works), it is pretty straightforward, and there's no added
>infrastructure. The downsides? Well, mainly that it relies fairly heavily
>on people, and there are a lot of points of failure.

Actually, you can automate as much or as little as you like, so long as you
use a framework outside of the core svn client (where it would be far too

Consider a script that wraps the svn client, for example, with a user
interface like this:

   % cs-svn help
   Changeset-SVN usage: cs-svn command options
   where command is one of:
     create - new copy of trunk in "/changesets/[newname]" where newname can
              be defined on command line or taken from a property kept on the
              changesets directory, incremented by one
     update - Merge changes from trunk onto branch, then update working copy
     submit - Add svn:submit property to the "/changesets/[newname]" directory
       list - List subdirectories of "/changesets" which have the "svn:submit"
      agree - Add your email address to the "svn:agreelist" property on the
              "/changesets/[newname]" directory
   disagree - Add your email address to the "svn:disagreelist" property on the
              "/changesets/[newname]" directory
    approve - Merge the branch back to trunk, remove the "svn:submit"
              property, and move the branch to an "/approved" directory.
              But a server-side script only allows this if the svn:agreelist
              and svn:disagreelist match with the local rules governing such
     cancel - Remove the "svn:submit" property, and move the branch to a
              "/cancelled" directory.

Well, you get the idea. Properties should probably not be in the svn
namespace, and it might work better with some sort of "state" property for
the branch, but I think the basic premise is sound. So long as people used
the cs-svn script (or whatever) consistently rather than trying to do it
all manually, I think that most of the problems you foresee above disappear.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:06 2006

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

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