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.
+By the end of 90 minutes, the instructor should be able to get
+learners to fetch upstream updates, make local edits, and submit their
+changes upstream and why that's a good way to structure development.
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).
+covered in 90 minutes.
Teaching notes
--------------
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.
+ `blame` is only compelling if a file has been edited by at least two
+ people.