7

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.

dukeofgaming
  • 14,023
  • 6
  • 52
  • 77

3 Answers3

12

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.

Martin Geisler
  • 893
5

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.

Tom Clarkson
  • 1,332
1

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.

Michael Durrant
  • 13,399