X-Git-Url: http://git.tremily.us/?p=swc-version-control-svn.git;a=blobdiff_plain;f=version-control%2Finstructor.md;fp=version-control%2Finstructor.md;h=78f16f0d09e74a473b73b96c0ab6790844868572;hp=9fe2757739cad58af86641a74497ef4d779b4e05;hb=1bdd155b3bbe3c84eb2d7c199c581c913448f200;hpb=b702e7ace1cd14a6ed6441390729d59dc8f7992f

diff --git a/version-control/instructor.md b/version-control/instructor.md
index 9fe2757..78f16f0 100644
--- a/version-control/instructor.md
+++ b/version-control/instructor.md
@@ -1,25 +1,10 @@
 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
 --------------
@@ -37,34 +22,9 @@ 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.