I suspect that I'm focusing on the wrong problem so I will first describe what I think the problem is before presenting the possibly suboptimal solution I envision.

Current Situation:
Currently my co-workers commit their code changes only after loooong periods of time in huge chunks with changes spreading all over the project(s). That's progress I guess, because not long ago they just put .zip archives on some network share. Still, merging is a nightmare - and frankly I've had enough of it. And I'm also tired of talking and explaining and begging. This just has to stop - without me constantly being "the bad guy".

My solution:
Since there seems to be no awareness of and/or no interest in the problems and I cannot expect any efforts to last longer than a few days ...strike that, hours, I'd like the subversion server to do the nagging.

My question:
Am I way off-base here or am I looking at the wrong problem? It seems like I'm missing something, and I think I'm asking the wrong thing by looking at tools to solve my problem.

Should I be looking for a tool to solve this problem or what is it I should do to fix this?

  • Aren't the troubles they have merging an incentive for them to want to improve the way they work?
    – Flosculus
    Dec 16, 2014 at 11:19
  • 1
    Just one idea, make them merge the code ;) But one thing that blocks me in SVN from committing often is, that it takes very long compared to git for example...
    – Knerd
    Dec 16, 2014 at 11:34
  • 5
    Who takes responsibility for resolving conflicts after someone performs a merge?
    – Flosculus
    Dec 16, 2014 at 13:54
  • An approach that's high on branching can give the best of both worlds; if you're doing a large job on a branch and regularly merging the master branch into that branch (so all merges are small) then when you finally merge the branch back into master that merge is trivial, but in the meantime you haven't got an intermediary state on master that is broken or otherwise confusingly incomplete. It's easier with some SCMs than other (depending on how light branching is), but it can work with any of them.
    – Jon Hanna
    Dec 16, 2014 at 14:10

2 Answers 2


You're looking for a technical solution to a human problem. That rarely works.

The reason for that is because if team members do not accept something (nor understand the implications), instead of following the rules, they'll attempt to circumvent them. That's exactly why, for example, developers should accept and understand style rules instead of just being forced to comply by a checker.

Here are a few approaches I either used in the past or have in mind without actually having an opportunity to them in practice. Some may not apply to your case, depending on the position you have in a team (if you're a team lead with excellent reputation, chances are you'll have a better opportunity to enforce your view than if you're an undergraduate who just joined a team for the duration of your internship).

  1. Discuss the issue with your coworkers and explain the consequences of large commits. Maybe they simply don't understand that complicated merges are a direct consequence of rare commits, and than small, frequent commits will make merges (relatively) easy.

    I knew a lot of programmers who were simply convinced that merges are always complicated. They did at most one commit per day, avoided to use powerful tools such as Visual Studio's diff and auto-merge, and had a poor practice of manual merging (unless “Take mine” with no further diff inspection is actually a good practice). For them, this had nothing to do with them, and was the inherent nature of a merge.

  2. Give concrete examples of what is happening in other companies (especially the ones your coworkers have a deep respect for). They may simply be unaware that it is an issue, and be convinced that a maximum one commit per day is what every team does.

    Some people are unaware that there are teams of 5-10 members who make up to 50 pushes to production, which translates into an average of 5-10 commits per day per person. They may not understand neither how is it possible, nor why would anyone do it.

  3. Lead by example. Do enough small commits yourself. If possible, do a short presentation showing their and your merges side by side over a week (I'm not sure if extracting this sort of information is easy from a version control). Emphasize on the eventual mistakes they've done during their merges and compare it to the number of errors you've done (which should be close to zero).

  4. Use the “I told you” technique, when appropriate. When you see your colleagues suffer over a painful merge, loudly comment that small, frequent commits could make merges (relatively) painless.

  5. Explain that there is no minimum duration to make a commit. A commit may even correspond to a minor change made in a few seconds. Renaming a file, removing an obsolete comment, correcting a typo are all tasks which can be committed immediately.

    Programmers shouldn't fear doing a tiny commit, but rather aggregating many changes into one huge commit.

  6. Work with individuals instead of a team, when appropriate. If there is a person who particularly refuses to do frequent, small commits, talk with this person individually to see why is he refusing it.

    They may give perfectly valid reasons which may give you the hint about what's going on with a team. Some reasons I've heard myself:

    • “My teacher/mentor told me that the best practice is to do one commit per day.” It doesn't surprise me, given what I had to hear from my teachers in college.

    • “My colleagues told me that I should make less commits.” I've been told that too in some teams, and I understand their point. We had a log which was practically filled with my commits (not hard to do when four teammates don't even do one commit per day), which frustrated my coworkers.

    • “I thought small commits make it difficult to find a revision.” Somehow valid point, even when the team puts an effort into writing descriptive log messages.

    • “I don't want to waste too much space on our version control server.” The person obviously doesn't understand how commits are stored (nor how cheap the storage space is).

    • “I think a commit should correspond to a specific task.” Given that often, a task corresponds to some work to be done in one day (such as in visual management's task boards), this is not a coincidence. The person should then learn to make a difference between a task in a backlog (2 to 8 hours of work) and a logically isolated change which should be committed (a few seconds to a few hours of work). This is also related to point 5.

  7. Search for the reason the team is not doing commits more frequently. You may be surprised by the results.

    Recently, I mentioned in a different answer that speed of a commit matters, and even hundreds of milliseconds may push developers to commit on less frequent basis.

    Other reasons may include:

    • Overly complicated rules to write a commit message.

    • The rule which forces the developer to link the commit to a task from a bug tracking system.

    • The fear of breaking the build.

    • The unwillingness to deal with a risk of breaking the build right now: if you do a commit on Friday evening just before leaving, you can postpone dealing with broken build until Monday.

    • The fear of doing a merge.

  8. Determine whether developers understand that there are other benefits to commit often. For example, a Continuous Integration platform is a huge incentive to have frequent commits, since it allows to pinpoint precisely where the regression was introduced.

    I would rather prefer CI platform telling me that I broke the build in the revision 5023 which consists of a change in two methods in one file I did fifteen minutes ago, rather than in the revision 5023 consisting of changes which span four dozen files and represent 13 hours of work.

  • "You're looking for a technical solution to a human problem. That rarely works." - I know, but I'm just tired and already through with all your points. It's not my problem for much longer, yet ...
    – VolkerK
    Dec 16, 2014 at 11:54
  • @VolkerK: see my edit (the first two paragraphs of the answer). Do you have a CI server? When you've spoken with your coworkers, how do they explain their unwillingness to commit more often? Dec 16, 2014 at 12:13
  • 1
    @VolkerK This answer explains very well. You do not have a technical problem. The problem is with people refusing to follow the procedure. Dec 16, 2014 at 14:03
  • 1
    Towards point 3: The TortoiseSVN client can create various diagrams that visualize check-in behaviour based on different parameters (like time). It's actually quite interesting to evaluate them. I did this frequently back in the days we were using SVN. stackoverflow.com/questions/412129/… :)
    – Aschratt
    Dec 16, 2014 at 14:42
  • 2
    Thanks for the input but I took the other route and just gave notice ;-)
    – VolkerK
    Dec 16, 2014 at 16:23

An organization I contracted for in the past wanted to solve this same problem, and came up with a fairly good social solution: developers do not have their own computers. The development TEAM has computers, but any individual can be asked and expected to work on any development computer on any given day. So, checking in is the only way to make sure you can continue working on what you were doing yesterday!

Management then went around and surreptitiously reverted changes on computers after hours so that anything not checked in was lost. These "simulated computer failures" only had to occur a few times before the devs got on board.

Of course, it's important to explain the "why" of rules as well as the "what". Unless the "why" is made clear, they could just store their source on USB drives or something.

  • 4
    This is a terrible way to treat people. What happens when you think of something right before leaving and want to have it on the machine, but it's not complete (like doesn't build) so you don't want to commit it? Dec 17, 2014 at 3:13
  • 3
    And it is a waste of resources, because normally you have a set-up environment that fits well your needs. I had the same situation a long time ago, and got my own laptop after 4 weeks. I hated each day to setup all the same, just to do the work I was expected to do.
    – mliebelt
    Dec 17, 2014 at 19:41
  • 1
    Wow, this is a terrible idea for so many reasons. As already mentioned in the comments above, (1) it prevents any possibility of continuity from day to day and (2) denies people the ability to set up custom dev environments that stick around...
    – Ben Lee
    Dec 23, 2014 at 5:50
  • 1
    ...But it also (3) has the potential to destroy hours of work if someone forgets to check in code, or accidentally doesn't for some reason and (4) demonstrates to the devs that management does not trust them to follow rules, instead imposing the rules in a draconian manner, potentially making it an us-vs-them environment and (5) it has the potential to encourage them to circumvent the rules just to be productive.
    – Ben Lee
    Dec 23, 2014 at 5:51
  • Please, nobody implement this idea.
    – Ben Lee
    Dec 23, 2014 at 5:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.