Teaching materials for scientists

Tue Apr 16 22:44:36 UTC 2013

On Apr 16, 2013, at 1:56 PM, Greg Ward <greg at gerg.ca> wrote:

> Hi all --
...
> BTW, any tips/ideas/insights into teaching Mercurial to scientists
> would be welcome.

When I show people how to use hg, I start with a directory on their machine and show how easy it is to integrate hg into their workflow:

install hg
edit ~/.hgrc (I enable glog and record here as well)
hg init
hg add
hg com

Then after they do that a bit, I introduce glog, push, pull etc. to bitbucket and hg clone to create copies to try things out.

Emphasize that - when things work, commit with a useful comment so that they can get back.

I also emphasize that pull *does not* modify your files… so you can do it without fear.

Explain the possibility of "hg update -C" early on.  Many people seem to get stumped when a merge fails and they don't know what to do.

One other useful strategy when one has modifications, but are hesitant to commit them:

hg sum (find out the parent version)
hg diff > diffs.<num>
hg up -C <revision>

Then one can restore the state if needed by 

hg up <num>
hg import --no-commit diffs.<num>

If bitbucket could get their act together and turn on MathJaX for README.rst files, then I would be a very happy camper as I could use this for almost all of my documentation too.  Since these are displayed in subdirectories too, I find that they are a great way for organizing notes.

https://bitbucket.org/site/master/issue/5420/enable-mathjax-for-restructuredtext-files

Don't overlook using hg for papers too.  I find it invaluable to be able to use hg diff (and latexdiff) to see what changes collaborators have made.

Finally, I have some assorted notes here that may be of use… they are definitely not consistent yet though, so take with a grain of salt.
http://computernotes.wikispaces.com/Mercurial

Michael.
-----------------
P.S. Related to using hg for physics, here are some partially unresolved issues I am still trying to grapple with:

1) Managing multiple projects (I would really like to be able to clone *all* my work, but have found subrepos etc. to be very problematic).  mr seems to work quite well here:

http://joeyh.name/code/mr/

but I have to refine my workflow to properly deal with dependencies etc.

2) Large files.  Still searching for a good way of associating build products, and the outputs of long runs with source code.  I agree that they should not be included in the hg repo, but it sure is tempting.  Ideally I am looking for something that can check some central stores and download the latest generated data.  I could script all of this, but want it to work seamlessly for colleagues.  largefiles could probably be abused/modified to do this, but I have not had time to look into this in detail.  Use cases include:
  A) Storing results of length calculations: these should somehow be associated with version of source code, and may need some version control on their own (i.e. store the results of code used for published papers).
  B) Storing PDF files so that colleagues can download the latest build (sometimes they may not have the latest TeX updates, or may not have figures etc. preventing them from building).  Sometimes I keep an hg repo in a Dropbox for collaborators who have not bought into hg yet.

> 
> Thanks!
> 
>       Greg
> -- 
> Greg Ward                            http://www.gerg.ca
> <greg at gerg.ca>                       @gergdotca
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial