Is there a "dual user check-in" source control system?

Question

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.

Answer 1

Actually, it's a way to make sure the code is of low quality. Anything that inhibits "check-in often" is a bad idea.

Answer 2

Using subversion (for example), this could be achieved by using two branches with different access rights:

• You have the branch where everyone can commit (check-in) to
• Then you have another branch, where only one (or some) people are allowed write access. These people could then verify the commits on the first branch and merge them to the second branch if everything is OK.

BTW: I would probably not recommend this approach, because it might result in too much overhead. I would probably try another approach for code-reviews/-approval, e.g. using some tool such as ReviewBoard and do the code reviews with your whole team (to learn/improve).

Answer 3

I'm not aware of any SCM that will do this out of the box, mainly because this is a process/worflow issue not a source control management issue.
Also as other people have correctly said, discouraging regular check-ins to your depository is a bad thing and starts to undermine the point of having an SCM solution in the first place.
So you're going to have do some element of 'roll your own' as only you know the exact process you want to achieve.
Here's how I'd do it in perforce:
1) Every coder creates a user branch
2) All changes are checked into their user branch and never into the main branch
3) Coder requests that their code is promoted to main :
i) Code is reviewed ( either manually by syncing to their user branch or through some code review tool like CodeCollaborator or Crucible )
ii) Code is marked as 'clean'
4) User then integrates the main branch down to their user branch and resolves any merge conflicts
5) Code is then integrated up to main.

There are still issues to resolve with this approach i.e if between steps 4 and 5, someone else has integrated to main then step 4 will have to be done again so you might want to consider having a single integrator or having an exclusive lock on the main integration step

Answer 4

I've done this in TFS by removing checkin rights to the target group. They would save into shelvesets and notify a group of reviewers who has the "checkin as other" right.

(This should be a penultimate resort, but when code like this:

if (expr == false || expr.ToString() == "false") { ...

is common, one must take steps. Final step was to replace several members of the team and ensure new recruits were interviewed by us, not just the manager at the off-shore location.)

Answer 5

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.

Answer 6

The git tools have a concept of 'signed off by', which maintainers can use when merging or applying patches into their 'official' tree, whatever that means in your process. In a project like the Linux kernel, no signoff, no integration. You could use that process.