How to Encourage More Frequent Commits to SVN

Question

A group of developers that I am working with switched from VSS to SVN about half a year ago. The transition from CheckOut-CheckIn to Update-Commit has been hard on a number of users. Now that they are no longer forced to check in their files when they are done (or more accurately, now that no one else can see that they have the file checked out and tell them to check back in in order to release the lock on the file), it has happened on more than one occasion that users have forgotten to Commit their changes until long after they were completed.

Although most users are good about Committing their changes, the issue is serious enough that the decision might be made to force users to get locks on all files in SVN before editing. I would rather not see this happen, but I am at a loss over how to improve the situation in another way. So can anyone suggest ways to do any of the following:

1. Track what files users have edited but have not yet Committed changes for
2. Encourage users to be more consistent with Committing changes when they are done
3. Help finish off the user education necessary to get people used to the new version control paradigm

Out-of-the-box solutions welcome (ie: desktop program that reminds users to commit if they have not done so in a given interval, automatically get stats of user Commit rates and send warning emails if frequency drops below a certain threshold, etc).

Answer 1

Read the commit log and ask people about their status and when they will have checked in their changes. Committing whole pieces is better than committing as if it was a way to 'save'.

How can a developer finish something and forget to check it in? Is the delivery process such that the user runs a build from the developer's own machine?

Answer 2

Do you use any kind of bug/feature tracking software?
You could ask them to include revision number when they tick off the completed work.

Answer 3

I think the problem you have is actually lack of a contigous build system combinet with a tracking of bugs/features/changes. With a bug track system and a contigous build, the developer can claim 'complete' only after his changes made it to the automated build and a release containing the changes is built, passes build validation tests and is dropped on the release drop location. Since the only way for a change to 'make' it into a build is to check in (an possible reverse integrate the feature branch into the main branch/trunk), devs will have to check in, otherwise they'll never finish anything ever.

Answer 4

In a small development group, I've seen a daily email sent to the group' mailing list showing a summary of the checkins from the prior day and an unofficial 'horse race' showing number of checkins, total lines, etc within the last 30 days to be helpful. Obviously you can't use number of checkins as any kind of performance metric, but it was still fun and kept source control on everyones mind. "Hey, Joe just passed me on checkins this month, oh wait, I never checked in that code yesterday".

This also has other advantages as people come in in the morning and read it over their cofee or whatever it keeps what other people are doing in developers minds. When we get into 'code freeze' and are nearing a release, we actually change the email from just a checkin summary, to include the actual 'diffs' so that every line of code gets many-eyed right away.

Answer 5

...users have forgotten to Commit their changes until long after they were completed.

I think this is the problem right here. How can a feature/bugfix be "completed" if it isn't checked in? Do you have an issue tracking system that records outstanding issues? Do you have a continuous integration system that runs unit tests as soon as a checkin is made?

If developers are just off doing their own thing with no accountability, then it's not surprising that you're running into problems getting everybody to cooperate. You will need some kind of oversight (project manager? team lead?) who is responsible for making sure that individual developers are cooperating with the rest of the developer team.

Answer 6

Typically, the thing that encourages developers to commit frequently is self-preservation. When updates become difficult for them because of merge conflicts and they discover that the problem is alleviated by pushing their changes, they will commit more often.

It does sound like there is something fundamentally wrong, though. How are your developer's getting their changes into the released product without going through the VCS? You should close that back door.

Answer 7

Get an automated build machine (or at the very least one dedicated person doing builds), and deploy only from that machine. Then your code doesn't get deployed until you commit, and it helps ensure that nothing was left out of the repository.

Additionally, having at least a few members of a team committing early and often usually encourages others to keep up too, because the slow committer has to deal with more local merge conflicts.

Answer 8

A decent bug/feature tracker will allow you to add a bug number when you commit your changes. For example, if I'm running Redmine, I can commit with "Fixes #323" somehwere in my subversion commit message and it automatically closes bug/task 323 in Redmine. It's very little setup, you just have to tell redmine where the repository is, which is asks for anyway.

This way you can see which changes have been committed against each bug, and bugs without a commit will be open (unless manually closed). You can assign bugs to milestones, and before the release of a milestone, review the commits against the bug.

Trac also does this, as do many others.

Answer 9

Automate your builds and deployments, and make it part of the process that nothing is "done" until it is tested on the test server