is the review worth the productivity hit?
It depends on team "balance" and on how reviews are set up. Both are matters of management and teamwork, no amount of version control technological magic (centralized or distributed) can have a substantial influence on that.
If done wrong, productivity hit will of course kill any benefits of the review; the answer is though not to drop idea of reviews but to find out how to do it right.
One approach to find out if your reviews are OK is to use issue tracking tool to track time spent on reviews (some code review tools allow for that, too). If you find out reviews are taking quite a lot of time, invest some effort into finding the reasons and ways to improve things. Also, it wouldn't hurt to have regular 1:1s with team members to discover potential issues with code reviews.
If "best" programmers in the team are forced to spend hours digging through incomprehensible garbage produced by crappy coders, solution is to fire crap-makers, not to appeal to VCS technology.
- In one of the past projects I was assigned to review code changes done by permanently under-performing team member, in a component that took almost an hour to just build and run tests. I started reading the diffs and when I noticed an uncompilable change, I simply finished review, posted necessary comments and asked management to ensure that further review requests come with written confirmation that their code compiles. There were no "review requests" since and soon the guy left.
On the other side, when team is reasonably balanced, code reviews are fun and educative. In my prior project, we had a requirement for 100% code review and it neither took much time nor was distracting. There were bugs discovered through review, and there were debates about coding style and design choices, but that felt just... normal.
If code changes are being blocked for days... weeks from getting to QA for testing "because of reviews", studying about VCS tricks would be the least likely way to solve this problem. Instead one would better focus their effort on finding out issues in the way how review process is organized.
- - Oh integration of this change was much delayed because reviewer got suddenly sick, what a misfortune.
- Hello! Hell-lo-o-o, did you ever think of having backup reviewers to deal with cases like that?
git
any developer can have his own repo (on his personal computer) and a public personal repo (the one on a server, behindapache
) that he can only add changes to. The difference is, that only the lead developers repo is the "blessed one", the one from which everyone should checkout from. The lead checkouts code from developer's public repos and merges them to his public repo. You both have known/controlled iteration as well as source control at all times.