If you are worried about overloading them with technical info, I find it really easy to introduce people to version control with a "Contributing to a Book" metaphor. Where you have multiple authors and editors all working on a book at the same time, and it's important to know who changed what, and when.
Then, have them start using Git/SVN/Whatever to control any papers, notes, or assignments. I've taught multiple non-developer types how to use version control using this method.
That'd be my gut reaction too, but that might just be because we understand the importance of it. Attrition rates are really high in intro CS classes. When loops still seem like a difficult concept, is version control just one more thing too much? On the other hand, if you spend time before starting programming just learning version control with plain English text, are you encouraging students to drop because they're not getting to program like they expected? And when most projects are 10 to 15 lines long and done alone, is there an effective way to still show how version control is superior to the undo button?
A related but somewhat off-topic question: when do you start using version control on brand-new projects? I find myself hg initing and making my first commit once I've written something significant -- say around 150-200 lines of code.
If you are worried about overloading them with technical info, I find it really easy to introduce people to version control with a "Contributing to a Book" metaphor. Where you have multiple authors and editors all working on a book at the same time, and it's important to know who changed what, and when.
Then, have them start using Git/SVN/Whatever to control any papers, notes, or assignments. I've taught multiple non-developer types how to use version control using this method.