[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: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-02-11 17:14:47 CET

Sean Russell <ser@germane-software.com> writes:

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

I like this. It's pretty nice.

> == Pre-hook driven peer review
> 1) People work off the main trunk
> 2) Commits cause a pre-commit hook to stuff the commit into a queue

Specifically, the transaction built by 'svn commit' never gets
promoted into a revision. The transaction just sits on the server,
waiting indefinitely for review.

> 3) A 'queue-check' command pulls the next commit in the queue and displays
> the diffs.

To be clear, I assume you mean 'diff between the transaction and HEAD'.

> 4) An 'evaluate' command sends information back to the queue, with a yea,
> nay, request for information, or send-to-back.

All of this meta-information can be attached to the transaction itself
as transaction property(ies).

> 5) The queue adds the response to a running tally for the commit, and checks
> a commit rules file. The contents are something like:
> <commit type='bug-fix'>
> <minimum-yes>1</minimum-yes>
> <maximum-no>0</maximum-no>
> <ratio>2:1</ratio>
> </commit>
> where the types are things like 'bug-fix', 'design-change', 'major-overhaul',
> etc., and the rules are whatever; I'm using Apache-style rules for the
> example.
> 6) If the tally meets the commit conditions, the commit is processed. Any
> "no"s cause a message to be sent to the original committer.

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.