Teaching materials for scientists

[Angel Ezquerra]

On Tue, Apr 16, 2013 at 11:05 PM, John Wong <gokoproject at gmail.com> wrote:
> I think the best tutorial yet is the official quick guide:
> http://mercurial.selenic.com/guide/
>
> The best way is don't assume they are not software engineers. I am not
> against dumping a binary file into Hg because Hg can handle binary quite
> well.
> You have to separate out at least two usages:
> 1) use version control to keep track of source code
> 2) use version control to keep track of binary, computational artifacts
>
> #2 is still okay with mercurial, but remember there is a huge cost for pull
> and push.
>
> Here is how I would do it:
> 1. Treat them as CS 100 students new to software development and force them
> to pick up some standard, basic practices.
> 2. Teach them how to use Mercurial (hg init, fix hgrc, write a file, hg
> commit, oops, hg add, hg commit)
> 3. At some point, you want to put them into a group of two, and introduce
> the simple collaboration workflow (hg pull, etc)
>
> You probably have to allocate at least an hour. Just tell them why software
> engineers use VS. Why it's a good idea.
> Have them get a bitbucket account. With academic email address, they can get
> free private repo!
>
>
> Not from BB team, but a user BB :)
>
> Good luck!
>
>
>
>
>
>
> On Tue, Apr 16, 2013 at 4:56 PM, Greg Ward <greg at gerg.ca> wrote:
>>
>> Hi all --
>>
>> I seem to have volunteered to teach a bunch of physics grad students
>> and postdocs the basics of version control with Mercurial. Do you know
>> about any teaching materials I can "borrow" to get started? I suspect
>> the audience differs from programmers in several ways:
>>
>>   * might never even heard of version control, never mind used it
>>
>>   * doesn't really care about the craft of writing maintainable
>>     software -- the hook is more likely to be "get back the code that
>>     worked last week, collaborate easily with your buddy/supervisor,
>>     have an offsite backup"
>>
>>   * more likely to put giant binary data files into version control
>>     rather than giant binary dependencies or build outputs...
>>     it's still wrong, but differently wrong ;-)
>>
>>   * might be tempted to put small textual analysis results under
>>     version control, which I strongly suspect is wrong
>>
>> BTW, any tips/ideas/insights into teaching Mercurial to scientists
>> would be welcome.
>>
>> Thanks!
>>
>>        Greg

Greg,

if you suspect that they don't know much about version control I would
suggest teaching them how to use a GUI front-end to mercurial (e.g.
TortoiseHg). I think that will make it much easier for them to start
using the tool, it will make it more clear what is the DAG and will
just smooth things out quite a bit.

Motivated, more advanced users can them move on and start using the
command line tool when they feel they need it and are ready for it.

Also, I think that stressing the importance of having clear commit
messages is _very_ important.

Cheers,

Angel