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
  • 13,973

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
  • 16
  • " 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 – Lazy Badger Mar 12 '12 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. – Martin Geisler Mar 12 '12 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 – Lazy Badger Mar 12 '12 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. – Martin Geisler Mar 12 '12 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 – Michael Durrant Mar 12 '12 at 16:16
  • I'll just take this opportunity to self-advertise =) http://programmers.stackexchange.com/questions/35074/im-a-subversion-geek-why-i-should-consider-or-not-consider-mercurial-or-git-or – dukeofgaming Mar 12 '12 at 16:26
  • @MichaelDurrant - What does SVN do better than git? will give you some food – Lazy Badger Mar 12 '12 at 17:09
  • @LazyBadger - Having had to start using svn only after having used mercurial for a couple of years, svn felt incredibly clunky and difficult to use. hg was a breath of fresh air after years of VSS and RCS, but svn was a serious retrograde step for me. We are now starting to move over to git, but I do wish we'd chosen hg instead. – Mark Booth Mar 13 '12 at 13:29
  • @MarkBooth - svn after hg may show some rake in grass, sure (complex merging and renames-tracking are definitely weak part). I hope, Git-disaster will pass you and you stay with Mercurial – Lazy Badger Mar 13 '12 at 13:49
  • @MarkBooth - svn difficulties are heavy conditional- and workflow dependent. "Tools for tasks", not "Tasks for tools" help always (obviously). For linear history I use SVN long years – Lazy Badger Mar 13 '12 at 13:54
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,342
  • 10
  • 8
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,199