Enforcing source control

Question

Hello,

How do I set some group policy rule or mechanism to make sure that every developer commits their code to the source control?

I use visualsvn server with Ankhsvn client btw.

Thanks

Answer 1

These sort of policies are best enforced using peer pressure. Create an environment where it is the accepted practice to commit the code. Otherwise, it will become a drudgery and developers will find ways around it.

Answer 2

This really seems like a bad idea. Could you explain why you want to force check-ins?

Forcing check-ins will lead to broken builds and propagation of bad code. Check-ins should only be done when the code is in a running state and the user has time to review all their changes. Developers should be free to check something out, experiment with it, and throw away their changes. I do this all the time when I check out older revisions.

If what you're looking for is a forced backup, I would consider some other solution besides source control.

Answer 3

I think that the best way to enforce source control is to build a well formed "Software Development Culture" on your team.

Developers that well know the benefits of source control, won't hesitate about using it.

Recommended article:

• Check In Early, Check In Often

Answer 4

A continuous integration server might help encourage people to check in their code. If everyone gets on board with checking in code for nightly builds/unit test runs, I think everyone will start to see the benefits. I agree with previous answers that forcing people to check in might not be the best approach - it's probably better to encourage that behavior using something that will benefit the group.

Answer 5

Email everyone and tell them to use Source Control or be fired! I'm not one to tell people to give out threats or even to have many policies, but using source control is just one those things that people should just be on board with without question.

If people are not serious about source control, then there are two possibilities. 1) The setup is too hard, and you should simplify the process to make it a one step process to check in. 2) They are bad developers and need to go. Period!

Answer 6

Our basic policy is "If it's not in the source code repository it doesn't exist."

• Developers only get to mark tasks as "development completed" when they check in the code.
• Build your deliverable(s) only from a tagged set of source code (not some joker's workstation copy.)
• NOTHING that's not in source control goes into QA or Production.

Checking in broken code is considered bad form but is not punished (outside a little ribbing from those inconvenienced.)

I'd like to use continuous integration and configure broken builds to automatically back out the broken changes but I don't expect to be able to any time soon where I'm at.

Edit: We also require artifact numbers in the comment for each checkin. This prevents gratuitous changes that are unassociated with a requirement.

Answer 7

If you meet regularly with the team (like daily SCRUMs) and use some sort of tool such us Jira or Mantis or Rally, and you set up a trigger in your SVN system to link each commit to a task (or even better, a branch with a task, but unfortunately this is not that good with SVN) you can easily check if developers have checked in code to this task. Most of the integrations with issue/bug tracking system create an attach with the files modified in the commit, so it will be really easy to check.

This is not forcing, but it will help you enforce that all team follows the rule mentioned before: checkin early, checkin often.