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.
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.
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.