+Version control is the most important practical skill we introduce.
+as the last paragraph of the introduction above says, the workflow
+matters more than the ins and outs of any particular tool. By the end
+of 90 minutes, the instructor should be able to get learners to chant,
+"Update, edit, merge, commit," in unison, and have them understand
+what those terms mean and why that's a good way to structure their
+working day.
+
+Provided there aren't network problems, this entire lesson can be
+covered in 90 minutes. The example at the end showing how to use
+Subversion keywords to track provenance is the "ah ha!" moment for
+many learners. If time is short, skip the material on recovering old
+versions of files in order to get to this section instead. (The fact
+that provenance is harder in Git, both mechanically and conceptually,
+is one reason to keep teaching Subversion.)
+
+Prerequisites
+-------------
+
+* Basic shell concepts and skills (`ls`, `cd`, `mkdir`, editing
+ files).
+* Basic shell scripting (for the discussion of provenance).
+
+Teaching notes
+--------------
+
+* Make sure the network is working *before* starting this lesson.
+
+* Give learners a ten-minute overview of what version control does for
+ them before diving into the watch-and-do practicals. Most of them
+ will have tried to co-author papers by emailing files back and
+ forth, or will have biked into the office only to realize that the
+ USB key with last night's work is still on the kitchen table.
+ Instructors can also make jokes about directories with names like
+ "final version", "final version revised", "final version with
+ reviewer three's corrections", "really final version", and, "come on
+ this really has to be the last version" to motivate version control
+ as a better way to collaborate and as a better way to back work up.
+
+* Version control is typically taught after the shell, so collect
+ learners' names during that session and create a repository for them
+ to share with their names as both their IDs and their passwords.
+ The easiest way to create the repository is to use a server managed
+ by an ISP such as Dreamhost, or on SourceForge, Google Code, or some
+ other "forge" site, all of which provide web interfaces for
+ repository creation and management. If your learners are advanced
+ enough to be using SSH, you can instead create it on any server they
+ can access, and connect with the `svn+ssh` protocol instead of
+ HTTPS.
+
+* Be very clear what files learners are to edit and what user IDs they
+ are to use when giving instructions. It is common for them to edit
+ the instructor's biography, or to use the instructor's user ID and
+ password when committing. Be equally clear *when* they are to edit
+ things: it's also common for someone to edit the file the instructor
+ is editing and commit changes while the instructor is explaining
+ what's going on, so that a conflict occurs when the instructor comes
+ to commit the file.
+
+* Learners could do most exercises with repositories on their own
+ machines, but it's hard for them to see how version control helps
+ collaboration unless they're sharing a repository with other
+ learners. In particular, showing learners who changed what using
+ `svn blame` is only compelling if a file has been edited by at least
+ two people.
+
+* If some learners are using Windows, there will inevitably be issues
+ merging files with different line endings. `svn diff -x -w` is
+ supposed to suppress differences in whitespace, but we have found
+ that it doesn't always work as advertised.
projects / swc-version-control-svn.git / blobdiff