So, I'm preparing to consider the outcome of training a lot of people (>25) to use Mercurial coming from a centralized mindset. I've done it with individuals and had success with it, although the time invested in each one has been different and most of them have been both proactive and open to trying something new.

I was wondering if there was someone here with experience giving such training to a large group of people as I would like to find out what are the do's and don'ts... of course, this would be more oriented towards dealing with those resistant to change, and a don't I can come to think of is telling them to avoid cheat-sheets mapping commands, as Joel Spolsky suggests.

3 Answers 3


I work as a Mercurial consultant and I've found that it's not too hard to explain DVCS to new users, provided that you don't confuse them. So what I do is:

  • Emphasize the core principles. The history model in Mercurial is actually very clean and simple. In particular, I find that branches are modeled better in Mercurial than in, say, Subversion. Talk with the users about how working together should work in an ideal world: I do a bit of work on my machine, you do a bit of work on your machine and we later reconcile (merge) our work. Then show them how Mercurial implements exactly this model.

  • Emphasize the centralized workflow. A lot of guides and tutorials put a lot of emphasis on the distributed aspect of DVCS — my experience is that this is not very important! Especially not in an organization where you already use a big centralized VCS. The important part is the new and improved workflows.

  • Emphasize simple use cases. Let the users get hands-on experience from playing with the tool. First they will commit and push/pull with a central server. Later you can guide them through a more structured scenario where they create a feature branch, make some commits, and merge it back.

We've made some training material that we call a Mercurial Kick-Start. I've used it several times and it normally has enough content for two or three days, depending on how much I talk.

  • " Mercurial is actually a much more clean and simple system than, say, Subversion" - Sorry, Martin, but you choose (from my POV) bad comparison point. SVN is well-designed and implemented product Commented Mar 12, 2012 at 15:43
  • 1
    @LazyBadger: No problem, SVN is a very good centralized VCS. When I say that Mercurial is cleaner, I'm thinking of tags and branches. Subversion doesn't really have them! It has a cheap server-side delta copy mechanism and partial checkouts and people use those tools to emulate tags and branches. But nothing stops you from modifying /tags/1.0/README and checking that in. You can also branch /trunk/foo/ and so make a "partial" branch. That is super flexible, but not so clean. Commented Mar 12, 2012 at 15:55
  • Well, you could add "... in some aspects" and I said nothing. Because in current form I read it as "SVN is badly created tool" - it drive me mad, when I start compare SVN with TFS, ClearCase, Perforce Commented Mar 12, 2012 at 16:02
  • @LazyBadger: Sorry, that was not my intention. I've updated the answer a bit to better reflect what I tried to say. I hope you like it more now. Commented Mar 12, 2012 at 16:10
  • 1
    svn is very well-designed and implemented and has stood the test of time well. There. Now: it's also an older technology that lacks the functional advantages of git and Mercurial. I've heard dvcs complaints a lot from svn users but it seems to be folk that have not used a dvcs a lot in their job. Usually just 1 or 2 days tryout without a change in thinking. I would love to heard from someone who's used a dvcs for several months and also svn and picks svn over a dvcs. That would mean more to me. I've used both for months and I now :) at orgs with a dvcs and :( at orgs with svn. very imho Commented Mar 12, 2012 at 16:16

The most important thing is to have a clear idea of what the standard workflow will be - how you will use branches and what gets pushed to the central repository.

A DVCS can be used in many ways, from a centralized model with everyone working on a single branch to sharing changes between developers without having a central server at all. The command documentation reflects this so is quite confusing for new users.

If you have a clear workflow designed you can give the users a list of common tasks instead of a list of commands, and it can be as simple as what they are used to despite being entirely different.

If you are dealing with those who are truly resistant to change, you can use git-tfs or similar - that way you don't need to train anyone who hasn't seen how much better DVCS works for a specific project.


One item I one consider is to look at 'same name, different functionality' issues. One of these that I've experienced with a git(dvcs)-svn(cvs) paradigm is that branching is different. In svn one tends to branch more, this workflow partly reflecting the fact that you can't "commit locally". When svn folks move to git, they need to learn what branches mean in terms of workflow in git and how they are often used when folks are collaborators. This has tripped up more than one person.

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.