[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: Zack Weinberg <zack_at_codesourcery.com>
Date: 2002-02-12 08:52:04 CET

On Sat, Feb 09, 2002 at 09:19:06PM -0800, Sean Russell wrote:
> == 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 like this system for several reasons. First, it's all mechanism;
you can build whatever review/commit policy you like on top of it.
Second, you could have multiple branches per developer if you wanted,
which is a nice way to partition tasks (someone mentions this
downthread, I think). Third, it works well with a distributed or
disconnected repository model; I can apply stuff to my branch on my
laptop on an airplane somewhere, and be assured that nothing horrible
will happen when I get back to the net and sync up.


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.