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