Are there any source control systems that require another user to validate the source code “before” it can be checked-in?
I want to know as this is one technique to make sure that code quality is high.
Update:
There has been talk of “Branches” in the answers, and while I feel branches have there place I think that branchs are something different as when a developer’s code is ready to go into the main branch it “should” be checked. Most often though I see that when this happens a lead developer or whoever is responsible for the merge into the main branch/stream just puts the code into the main branch as long as it “compiles” and does no more checks than that. I want the idea of two people putting their names to the code at an early stage so that it introduces some responsibility, and also because the code is cheaper to fix early on and is also fresh in the developers mind.
A solution that attempts to address the problem is Kiln by FogCreek: http://www.fogcreek.com/Kiln/ – this shows that what you want is not at all unreasonable.
Generically I think that this is more about how you organise things that about specific tools, that said if a tool has features that help support the workflow you need then obviously that’s going to help.
I believe (though right now I’m struggling to find references) that there are tools that have the notion of a stop point prior to commit – so that the developer commits but the changes are “held” ’til approved. Either that or there are code-review tools that manage the hooks for you (I’m frustrated because I’ve read this stuff but can’t find it this morning).
Generally, from what I’ve seen, this suggests that a DVCS (mercurial, git, bazaar et al) might be the most appropriate solution – with the review step being the push to your central repository, this resolves the conflict between “commit often” and “review before commit”. The alternative – as suggested – is that you work on developer branches and review before merge. In both cases the key issue is more management than toolset – you need to ensure that backlogs don’t build up (of potentially “poor” code) because of an inability or lack of will to get code reviewed and integrated.