CVS tools to allow for code review / merge management

[Fran Fabrizio]

I'm looking to either use or write a tool that would allow us to achieve 
the following workflow with our CVS repository:

- Developers write code and commit changes
- Lead developer reviews the code changes, and either signs off on it or 
sends it back to the developer with comments
- When lead developer signs off on it, code is moved/merged into a 
'clean' repository from which clean builds/dists can be produced, 
testing suites run against, etc...

I searched for the better part of a day and haven't found anything that 
really performs this "merge management / source tree protection" role. 
I've found a few tools (Bonsai, codestriker) that allow for easy review 
of changes that have been made and allow for commenting on them but 
nothing that keeps developer commits from tainting a tree until approved. 
I've schemed up a fairly simple tool in my head that I could write that 
would fulfill my goals, but I wanted to see if you could shoot any holes 
in it, or tell me of other tools I may have missed.

For a first pass I was thinking of:
- making a devel branch and a main branch.
- all developers work off of devel branch at all times.
- i write a perl web tool with a db backend that tracks the last 
revision of each file that was approved by the lead developer and also 
can query cvs and find out the current revision
- perl web tool will be able to show lead developer all the changes that 
have yet to be approved that are on the devel branch
- lead developer can pull up diffs (I'll use ViewCVS or cvsweb for this 
functionality) and review the changes
- lead developer can send comments back to the code author (maybe via 
bugzilla?)
- lead developer can approve a change
- approval of a change leads to a merge of that file back onto the main 
trunk and tagging of that file on devel (so we'll know how far back to 
look the next time we need to merge this file)

Does such a (free) tool like this exist for cvs?  It would seem to be a 
common wish but I looked around at how some of these big projects manage 
this.  Mozilla, for example, once you have commit privileges you can 
commit right to the tree, you are -supposed- to get approval from a 
supervisor and run a test suite first and check Bonsai to see if the 
tree is open, etc... but they don't seem to have any mechanism to 
actually enforce this - i.e. a harried or irresponsible developer can 
commit to the main tree from which builds are produced without approval 
and without running appropriate tests and nothing would stop him.

I would like to know what the weaknesses are in my plan.  I already see 
one - that is that one developer could break the branch and prevent 
another developer from continuing work.  To thwart that I'd need to give 
each developer his own branch and the developers would have to do an 
update from the HEAD every now and then to benefit from the other 
developers' work.  For the number of developers we have right now (3) 
that might be overkill, and the main problem we're trying to combat is 
not developers stopping each other from working, but developers tainting 
the tree from which we produce distributions for internal testing and 
such.  However, maybe in the future each developer would need his own 
branch.  Another weakness is that I'll seemingly have to do the merging 
one file at a time back onto the trunk and track a lot of different 
tags, not too big of a deal right now, we have maybe 100 files total, 
but still inefficient.

So, what are the other holes in this approach and what work has already 
been done in this arena?

Thanks,
Fran