I have recently started working in a team where there is no version control. Most of the team members are not used to any kind of version control. I've been using mercurial privately to track my work. I would like to encourage others to adopt it, and at the very least start to version their code as they develop changes. Can anyone give me advice on how I can encourage adoption of a distributed version control such as mercurial. Any advice on how to win people including managers to DVCS would be much appreciated.

  • 4
    I would add an answer, but I can't. I am speechless (or rather, typeless). It's been almost 40 years since SCCS first appeared. Are there still organizations out there that don't use version control for anything but the simplest of projects? (Nowadays its the other extreme; some people have their home directory as a git repository.) Jul 17, 2011 at 22:58
  • 11
    Don't encourage it; demand it. Jul 17, 2011 at 23:40
  • 1
    The company I am with now consults with far larger companies than we are and I have yet to run into one that is using source control... After thinking about that statement, I can suddenly see why they needed someone else to fix their problem. The first thing we do usually is demand they set it up so we can use it to integrate and manage their changes and ours. As @SnOrfus stated, demand it. You can point to all the documentation that has it noted as a best practice as well. Jul 17, 2011 at 23:50
  • 7
    I'm with SnOrfus. There are some good answers here, but ultimately, if you don't get a positive reaction immediately, it's time to go. Like David Hammen, I'm speechless that in 2011 any developer is in a situation where they need to deal with an issue like this. Lack of version control is a dysfunction that is just not acceptable. Jul 17, 2011 at 23:55
  • 2
    Sneak in one night and delete their hard drives. No, sorry. Temporary lapse of professionalism there. Jul 18, 2011 at 1:56

6 Answers 6


You need to make a case for the use of version control, and first try to sell it to your co-workers, and if that fails, up the chain to project leadership and higher.

To fellow software engineers, your case should be focused on how it saves time and headaches in the long run. Find times from your own past, or published stories (blogs, articles in magazines, white papers) on how the use of version control makes your life easier. If you've been burned by not having version control, make it personal. If your fellow developers have been in the same situation, they should see the light and how these tools can help them.

This is your best bet. Although I can't find the source(s) right now, I've read (in a couple of places) that the most effective changes to process comes from the developers, who have to deal with the changes. If you can get the developers on board, you achieve two things. First, you already have the buy-in from the people who will be impacted by the process change. Second, there is a group of people to convince management that this is a worthwhile effort and will improve the product and project.

However, if you can't get the support of the development team and you still feel incredibly strongly about deploying version control, then you can move up to management. But it becomes riskier if you are going solo, since you not only have to worry about selling the improvement, but also dealing with backlash from your colleagues.

To project, program, and organizational management, the case has to be on how deploying version control can save the organization time and money. The people at this level care about how much money the project is costing, where it stands compared to estimates, and so on. Look for white papers, books, articles, and other professional documents and publications that explain how deploying version control have saved other organizations time and money in the long run. You can also introduce a quality perspective here, if your organization is interested in software quality.

You specifically mentioned that you want to use a distributed version control system. Don't force that down the throat of the team or organization. Introduce them to version control and their options. Although you personally might prefer using a DVCS (like Mercurial), it might not be the best fit for your team and organization. Using a tool that's the wrong fit will only make matters worse through thrashing.

Also, be aware of the risks of introducing process late. Although the use of version control is a commonly accepted best practice, it might be too late to effectively introduce it on the current project without a huge risk to project completion. Instead, I would recommend a focus on improving the status quo for future projects and teams.

Also, this is a general approach that you can follow for carrying out any process or technology improvements.


The first question is: what do they do currently? Surely each developer doesn't have the source code stuck on his own box that he changes at will. Once you have the process they currently follow, you can suggest some tools that enhance this process - usually a SCM is ideal to help them with this, rather than make them follow a different process.

The main point here is, if they have a pseudo-SCM way of working, maybe storing the current version on a server somewhere, then you need to determine if a DVCS or a CVS is more appropriate, don;t try to sell them Mercurial if SVN is a better fit.


The quickest way is to convince management that it's needed.

Do some calculations:

Cost of version control software - free.
Cost of hardware to support repository - one server.
Cost of implementing software - a couple of man days for a small team, rising for larger teams.

Cost of not implementing version control:

Best case - days lost due to edits going missing, overwriting each others changes etc., bugs recurring and so on.
Worst case - however many man years of effort your team has expended so far.

This latter figure is the worst case scenario of you losing all your work due to server failure etc. but even the "best case" scenarios should bring home to them why it's needed. The cost of recurring bugs could be greater as it could lead to lost customers.

The development team should also understand these costs and given that most (if not all) version control software integrates seamlessly with IDEs these days they won't even notice it's there most of the time.

  • Cost of version control software is not free. The software itself is might be free (depending on your selection), but in an organization that has nothing, you need training for the engineers, you might need hardware for the repositories to reside on, and if the organization rolls it out to everyone, an increase in IT funding to support the new hardware and software requirements. Not to mention the high risk of deploying process late in a project.
    – Thomas Owens
    Jul 17, 2011 at 20:31
  • @Thomas - hence my line about the cost of implementing it (which is probably an underestimate)
    – ChrisF
    Jul 17, 2011 at 20:33
  • The edit makes it much better.
    – Thomas Owens
    Jul 17, 2011 at 20:37

Management usually cares most about saving money. Emphasize how version control can benefit the team financially and you'll get their attention right away!

  • Management does, but it's always easier to get management's attention if you have a group of people saying something, rather than an individual.
    – Thomas Owens
    Jul 18, 2011 at 2:10
  • @Thomas indeed, more voices create more noise and thus more likely to get managements attention
    – rrazd
    Jul 18, 2011 at 7:19

There is one aspect that other folks here haven't touched on that I think you've got in your corner - you're talking about distributed version control - by its very nature, you can sneak it into a de facto practice, one developer at a time. With a stuffier version control, like what we use in my office (MS Visual SourceSafe), you'd have a hard time going up to the guy in the cube across from mine and selling him, one-on-one on the merits of version control. However, with (any) DVCS, you can just say "hey, try this, and see if you like it. I'll show you the ropes, and I'd be happy to answer any questions, walk you through, blah blah blah". That way, you don't need a "process" from down on high, you can build a grassroots mandate, one person at a time.


Building on gbjbaanb's answer.

The key thing here is you should adapt the version control process to whatever existing process exists and show how it saves the rest of the team effort.

I personally favour Mercurial as well but I wouldn't necessarily want to foist it on people unaccustomed to version control because it is a little harder to comprehend than an old fashioned server based locking version control system. That said if it's a true greenfields site it might be best to go the whole hog, skip the '80s & '90s and go with Mercurial. I'd also look at some of the 3rd party software lifecycle stuff built around Mercurial - I'm sure there's one but its' name escapes me ;)

I'm guessing that you work for a small company & that you are relatively new to the team so it might be a hard sell - especially if the rest of the team is entrenched and has the trust of management. Might be best to let them stuff something up badly then come to the rescue. That doesn't mean sabotage, just wait for the inevitable.

  • Thanks for all your responses,can this question be made a community question? The powers that be are letting me give a brief talk/demo 15mins on how I have been using it. One hurdle is who uses it? Is it some shareware/bloatware off internet? I would like to calm fears by pointing to some well known companies who are using/supporting Mercurial(any DCVS) commercially. Could anyone help me cite some companies who make use of Hg? Or other well known product using it. There's resistance (unspoken-eyes glaze over) to open-source, some managers seem suspicious of software that they don't pay for. Jul 29, 2011 at 16:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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