I think performing manual code reviews is... well... kinda 80's. Well, maybe 90's.
In this modern era of continuous integration and online code review systems, you really don't want to hold back any code commits just because you're afraid that "it might break source control".
Come on, people. That's what changeset (or change lists) are for. You make your programmers feed the hungry maws of your source control system. Then your continuous integration server kicks in with a litany of targeted builds (well, hopefully just the daily build, but some of us get carried away). If anything breaks, you put the code monkey trophy (usually a plastic toy that someone found from a Lucky Charms cereal box) on the perpetrator's desk, and roll back the breaking change list. Well, some continuous integration systems automatically blasts out email/IM/desktop notifications to everyone in the team/department/organization that the build is broken, along with a nifty hyperlink to show everyone who exactly broke the build in which file or test. It's now the hapless programmer's job to fix whatever broke the compile/unit test/integration test/etc.
As this process runs on, the code review system kicks in (again, triggered by the check in). A list of qualified team members are notified of the change list being committed to source control, a review is started in the review system, and everyone starts to make annotations to the changes in the change list. Hopefully everyone will say "LGTM". If the programmer is smart, he will remember to pray/bribe/hide. If there are serious issues, the reviewers can create a defect (which can be hooked into the bug tracking system), or even require the changelist to be backed out. Yes, backed out changes hurt not only the ego, but the mind, that is true. It is a good seasoning on the junior developers, to reintegrate rejected change lists.
If your dev environment is lacking a CI or a code review system, you should seriously investigate these. A couple of links might help you:
If you're going to get a CI server, you should also seriously think about unit test frameworks. If you're a C# dev, look into something like NUnit to get started.