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

Peer-reviewed commits (design ideas)

From: Sean Russell <ser_at_germane-software.com>
Date: 2002-02-10 06:19:06 CET

Hash: SHA1


I'm trying to nail down how we want this to work, before I start on the

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

== 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
3) A 'queue-check' command pulls the next commit in the queue and displays
the diffs.
4) An 'evaluate' command sends information back to the queue, with a yea,
nay, request for information, or send-to-back.
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'>
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
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.

This is nice, because it offers more structure than the other system, but it
also will require more tools and configuration. I'm not really sure how
conflicts would be handled, and how are these things rolled back on failure
(too many nay votes, something in the commit needs to be changed, etc), since
they've already been 'committed', as far as the client is concerned, but
haven't been as far as the server is concerned. (Sorry about that sentance).
Also, "push-to-back" would be important, but it flirts with trouble from
out-of-order commits. The whole thing stinks of being problematic to
implement, but I like it more in many ways.

A /.-like interface could be layered on top of either of these; I don't think
thats a consideration.


- --
 |.. Unix is an operating system.
<|> OS/2 is half an operating system.
/|\ Windows is a shell.
/| DOS is a bootsector virus.
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org


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.