version-control/README.md: Add a motivational paragraph
authorW. Trevor King <wking@tremily.us>
Mon, 24 Jun 2013 13:55:13 +0000 (09:55 -0400)
committerW. Trevor King <wking@tremily.us>
Wed, 23 Oct 2013 04:05:43 +0000 (21:05 -0700)
The text is adapted from 3976755 (Added the file for lesson 2,
2012-02-04), which I cherry picked out of boot-camps (where it is
d48ceea) [1].

[1] https://github.com/swcarpentry/boot-camps

Lesson-2:-Version-Control.rest [deleted file]
version-control/README.md [new file with mode: 0644]
version-control/cheat-sheet.md [new file with mode: 0644]
version-control/instructor.md [new file with mode: 0644]
version-control/svn/README.md [new file with mode: 0644]
version-control/svn/instructor.md [new file with mode: 0644]

diff --git a/Lesson-2:-Version-Control.rest b/Lesson-2:-Version-Control.rest
deleted file mode 100644 (file)
index 4c246bc..0000000
+++ /dev/null
@@ -1,320 +0,0 @@
-
-----------------------------------------------------------------------------------
-What is Version Control
----------------------------------------------------------------------------------- 
-
-Very briefly, version control is a way to keep a backup of changing files, to
-store a history of those changes, and most importantly to allow many people in
-a collaboration to make changes to the same files concurrently. There are a lot
-of verson control systems. Wikipedia provides both a nice vocabulary list and a
-fairly complete table of some popular version control systems and their
-equivalent commands.
-
-Today, we'll be using SVN. Perhaps someday we'll have a second section of this
-experiment to go over distributed version control systems like mercurial.
-
----------------------------------------------------------------------------------- 
-Checking Out The Code
----------------------------------------------------------------------------------- 
-
-The Hacker Within has its own online code repository. You can check out code
-from it at any time, from anywhere. You checked out some code this morning from
-it at googlecode http://code.google.com/p/scbc-2011 in smartsvn. If you gave me
-a google id, you are a fully fledged reading writing member today. Remember,
-with great power comes great responsibility.
-
-Today, we'll check out an svn type repository at scbc-2011.googlecode.com/svn/
-.
-
-********************************************************************************** 
-Exercise : Checking out the code
-********************************************************************************** 
-
-Step 1 : Open up an internet browser and log in to google.
-
-Step 2 : Now go to the Checkout the source tab and click on the Password link.
-Take Note.
-
-Step 3 : Either do this in SmartSVN or crack open a terminal. In SmartSVN,
-click on the radio button that says check out project from repository. The
-repository location is https://scbc-2011.googlecode.com/svn/ .
-
-In the terminal, if your google user name is buckybadger, do this:
-
-::
-
-  ~$ svn checkout https://scbc-2011.googlecode.com/svn/ \
-  scbc-2011 --username buckybadger
-
-Step 4 : You should see many files download themselves onto your machine. Let's
-make sure it worked. Either browse in SmartSVN or change directories to the
-source code and list the contents.
-
-::
-
-  ~$ cd scbc-2011 ~/scbc-2011$ ls 
-
-
----------------------------------------------------------------------------------- 
-Checking The Status of Your Local Copy
----------------------------------------------------------------------------------- 
-
-The files you've created on your machine are your local "working" copy. The
-changes your make in this local copy aren't backed up online automatically.
-Until you commit them, the changes you make are local changes. When you change
-anything, your set of files becomes different from the files in the official
-repository copy. To find out what's different about them in the terminal, try:
-
-::
-
-  ~/scbc-2011$ svn status 
-
-
-The null result means that you're up to date with the
-current version of the repository online! There are a few other responses you
-might get if you or your collaborators have been active. We'll see what they
-are as we go along.
-
----------------------------------------------------------------------------------- 
-Updating
----------------------------------------------------------------------------------- 
-
-Updating is like voting. You should update early and often , and particularly
-before you make or commit any changes. This will ensure you're working with the
-most up-to-date version of the repository. Updating won't overwrite any changes
-you've made locally without asking, so don't get nervous. When in doubt,
-update.
-
-:: 
-
-  ~/scbc-2011$ svn update 
-  At revision 19.
-
----------------------------------------------------------------------------------- 
-Adding New Files to Version Control
----------------------------------------------------------------------------------- 
-
-This is great. You can make some changes, and commit them to version control.
-But, what if you want to add something totally new? How do you make changes to
-a file that doesn't exist yet?
-
-********************************************************************************** 
-Exercise : Adding files to Version Control
-********************************************************************************** 
-
-Step 1: Create a wiki page about yourself. Please tell us about yourself. Save
-a file to the folder called wiki. Call it something unique, like
-buckybadger.wiki. Take your time.
-
-:: 
-
-  ~/scbc-2011$ vi buckybadger.wiki
-
-Step 2: Check the status of your local copy For kicks, let's see what SVN
-thinks of this.
-
-::
-
-  ~/scbc-2011$ svn status
-
-SVN should report that it hasn't yet been officially introduced to your file.
-
-::
-
-  ? buckybadger.wiki
-
-Step 3: Add the file to version control Now, introduce your file to svn by
-adding it to version control.
-
-::
-
-  ~/scbc-2011$ svn add wiki/buckybadger.wiki
-  A wiki/buckybadger.wiki
-
-If you want to, commit that change. Your wiki page will be available for anyone
-to see on the repo. When your done, give it a look online at
-scbc-2011.googlecode.com/wiki.
-
-::
-
-  ~/scbc-2011$ svn commit -m "In commit messages, we usually explain what we've \
-  done. Here, we've added a wiki page." 
-  Adding wiki/buckybadger.wiki 
-  Transmitting file data . 
-  Committed revision 86.
-
----------------------------------------------------------------------------------- 
-Removing Files from Version Control
----------------------------------------------------------------------------------- 
-
-But, let's say you're shy and change your mind about adding this to version
-control. Not all pretty faces belong on the internet, after all. If you change
-your mind, and would rather not add this wiki page, try svn remove. You can
-also just say rm. Be careful, this will delete your local copy of the file.
-
-::
-
-  ~/scbc-2011/wiki$ svn remove buckybadger.wiki 
-  D buckybadger.wiki 
-  ~/scbc-2011/wiki$ svn commit -m "a log message" 
-
-Deleting hacker-poke/data/myPic.png Committed revision 87.
-
-Making and Committing a Change
-
-Now, recall the software-carpentry.org tutorial. You're Wolfman. The guy next
-to you, he's Dracula. I'll be the Mummy. Please pick a random place in one of
-the files and insert a comment, like an easter egg.
-
-********************************************************************************** 
-Exercise : Making Changes
-********************************************************************************** 
-
-Step 1 : Insert something
-
-If you're not in the terminal, just open up the ReadMe.wiki file.
-
-If you're new to the command line, you can open the best text editor like so:
-
-::
-
-  ~/scbc-2011$ cd wiki 
-  ~/scbc-2011/wiki$ vi ReadMe.wiki
-
-Once it's open, you'll see some text. Just type the letter 'i' and place a line
-anywhere you like. The line is a comment if it begins with a pound sign #, like
-so:
-
-::
-
-  #summary A Readme for the Repository
-  =Read Me=
-
-  #KATY'S COMMENT
-  ==Software Dependencies== 
-  * Python 2.71 (or greater?) 
-  * Nose 
-  * Idle 
-  * sqlite (3?) 
-  * Smart SVN ? 
-  * add more here...  
-
-
-To save it, press 'ESC', then ':wq' .
-
-Step 2 : Check the status of your local copy
-
-Now that you've changed a file, let's see what SVN thinks about your local
-status.
-
-::
-
-  ~/scbc-2011$ svn status 
-
-  M ReadMe.wiki
-
-
-If you want, try committing your change. If it's a comment, it won't break
-anything. If you think someone else has committed recently, don't forget to
-update first.
-
-:: 
-  
-  ~/scbc-2011$ svn update
-
-
-If SVN lets you know that someone else has committed changes to the same file
-recently, hang on and watch until the next section on conflicts. If svn doesn't
-complain, commit.
-
-Step 3 : Commit
-
-::
-
-  ~/scbc-2011$ svn commit -m "The m flag indicates that you'd like to leave a log \
-  message saying what you've done. Here, we each added a comment."
-
-The m flag allows you to add a comment that will be stored in the repository to
-help your collaborators keep track of the changes.
-
----------------------------------------------------------------------------------- 
-Resolving Conflicts
----------------------------------------------------------------------------------- 
-
-Some of you may have received an error message about a conflict.
-
-********************************************************************************** 
-Exercise: Resolving Conflicts
-********************************************************************************** 
-
-Step 1 : Update Before Committing
-
-:: 
-
-  $ svn update 
-
-  U ReadMe.wiki
-
-  Conflict discovered in 'ReadMe.wiki'. 
-
-  Select: (p) postpone, (df) diff-full, (e) edit, (h) help for more options:
-
-Step 2 : Postpone 
-
-
-The options are many :
-::
-
-  (p) postpone - mark the conflict to be resolved later (df) diff-full - show
-  all changes made to merged file (e) edit - change merged file in an editor (r)
-  resolved - accept merged version of file (mf) mine-full - accept my version of
-  entire file (ignore their changes) (tf) theirs-full - accept their version of
-  entire file (lose my changes) (l) launch - launch external tool to resolve
-  conflict (h) help - show this list For now, you want to do some analysis, so
-  press p to postpone.
-
-  $ p
-
-Step 3 : Check the Differences
-
-Try diff (or meld if you have it).
-
-::
-
-  $ diff myfile1.py myfile2.py Step 4 : Resolve the Conflict
-
-The svn command resolve in combination with --accept and one of the choices
-from before will automatically delete the right files. Alternatively, you could
-delete all of the files that you don't like, move the correct one to the right
-filename, and try committing again. For now, we'll do it the clean way. For
-example, pretend you'd like to accept yours rather than the other.
-
-::
-
-  $ svn resolve --accept ReadMe.wiki.mine Resolved conflicted state of
-  'ReadMe.wiki'
-
-Importantly, if you decide to neglect all of your changes instead, you can
-choose to revert. Try svn help revert to find out how to do that.
-
-::
-
-  $ svn revert ReadMe.wiki
-
-
----------------------------------------------------------------------------------- 
-A test
----------------------------------------------------------------------------------- 
-
-Okay Wolfmen, open up KatyHuff.wiki and replace my name with your own (or
-someone else's, in case you're shy).
-
-Now, clearly we've all just tried to change the same thing at once. The first
-one of us to update and commit will have no problems. However, when the rest of
-us try, SVN won't let us merge our changes. We have to talk this one over and
-decide who gets to commit. The rest of us will have to resolve conflicts as we
-learned. Try it!
diff --git a/version-control/README.md b/version-control/README.md
new file mode 100644 (file)
index 0000000..6d488f9
--- /dev/null
@@ -0,0 +1,113 @@
+Version control is a way to keep a track of changing files and store a
+history of those changes and the motivation behind them.  This
+organized history allows many people in a collaboration to make
+changes concurrently, while staying up to date with changes made by
+their collaborators.  It also makes it easy to keep yourself organized
+if you store similar files in several different locations (e.g. a
+project that you develop on both your home computer and your work
+computer).
+
+Basic use
+=========
+
+Learning objectives
+-------------------
+
+* Draw a diagram showing the places version control stores
+  information.
+* Check out a working copy of a repository.
+* View the history of changes to a project.
+* Add files to a project.
+* Commit changes made to the working copy.
+* Get changes from an upstream repository.
+* Compare the current state of a working copy to the most recent
+  update from the upstream repository.
+* Explain what "version 123 of `xyz.txt`" actually means.
+
+Key points
+----------
+
+* Version control is a better way to manage shared files than email or
+  shared folders.
+* People share their changes by committing them to public repositories
+  and fetch other's changes by updating their local copy from public
+  repositories.
+* The version control system prevents people from overwriting each
+  other's work by making merges explicit.
+* It also keeps a complete history of changes made to the master so
+  that old versions can be recovered reliably.
+* Version control systems work best with text files, but can also
+  handle binary files such as images and Word documents.
+* Every repository is identified by a URL.
+* Each change to the master copy is identified by a unique revision
+  ID.
+* Revisions identify snapshots of the entire repository, not changes
+  to individual files.
+* Each change should be commented to make the history more readable.
+* Commits are transactions: either all changes are successfully
+  committed, or none are.
+
+Merging conflicts
+=================
+
+Learning objectives
+-------------------
+
+* Explain what causes conflicts to occur and how to tell when one has
+  occurred.
+* Resolve a conflict.
+
+Key points
+----------
+
+* Conflicts must be resolved before a commit can be completed.
+* Most version control systems put markers in text files to show
+  regions of conflict.
+
+Recovering old versions
+=======================
+
+Learning objectives
+-------------------
+
+* Discard changes made to a working copy.
+* Recover an old version of a file.
+* Explain what branches are and when they are used.
+
+Key points
+----------
+
+* Recovering an old version of a file may not erase the intervening
+  changes.
+* Use branches to support parallel independent development.
+
+Setting up a repository
+=======================
+
+Learning objectives
+-------------------
+
+* How to create a repository.
+
+Key points
+----------
+
+* Repositories can be hosted locally, on local (departmental) servers,
+  on hosting services, or on their owners' own domains.
+
+Provenance
+==========
+
+Learning objectives
+-------------------
+
+* What data provenance is.
+* How to embed version numbers and other information in files managed
+  by version control.
+* How to record version information about a program in its output.
+
+Key points
+----------
+
+* Put version numbers in programs' output to establish provenance for
+  data.
diff --git a/version-control/cheat-sheet.md b/version-control/cheat-sheet.md
new file mode 100644 (file)
index 0000000..94d1ba3
--- /dev/null
@@ -0,0 +1,20 @@
+Basic use
+=========
+
+Merging
+=======
+
+Comparing changes
+=================
+
+Browsing history
+================
+
+Recovering old versions
+=======================
+
+Setting up a repository
+=======================
+
+Provenance
+==========
diff --git a/version-control/instructor.md b/version-control/instructor.md
new file mode 100644 (file)
index 0000000..78f16f0
--- /dev/null
@@ -0,0 +1,30 @@
+Version control is the most important practical skill we introduce.
+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.
+
+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.
+
+* 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
+  `blame` is only compelling if a file has been edited by at least two
+  people.
diff --git a/version-control/svn/README.md b/version-control/svn/README.md
new file mode 100644 (file)
index 0000000..3131911
--- /dev/null
@@ -0,0 +1,77 @@
+In addition to the generic version control objectives and points.
+
+Basic use
+=========
+
+Learning objectives
+-------------------
+
+* Explain why working copies of different projects should not overlap.
+
+Key points
+----------
+
+* The master copy is stored in a repository.
+* Nobody ever edits the master directory: instead, each person edits a
+  local working copy.
+* The basic workflow for version control is update-change-commit.
+* `svn add <em>things</em>` tells Subversion to start managing
+  particular files or directories.
+* `svn checkout $URL` checks out a working copy of a repository.
+* `svn commit -m "$MESSAGE" $THINGS` sends changes to the repository.
+* `svn diff` compares the current state of a working copy to the state
+  after the most recent update.
+* `svn diff -r HEAD` compares the current state of a working copy to
+  the state of the master copy.
+* `svn history` shows the history of a working copy.
+* `svn status` shows the status of a working copy.
+* `svn update` updates a working copy from the repository.
+
+Merging conflicts
+=================
+
+Learning objectives
+-------------------
+
+* Identify the auxiliary files created when a conflict occurs.
+
+Key points
+----------
+
+* For each conflicted file, Subversion creates auxiliary files
+  containing the common parent, the master version, and the local
+  version.
+* `svn resolve $FILES` tells Subversion that conflicts have been
+  resolved.
+
+Recovering old versions
+=======================
+
+Key points
+----------
+
+* Old versions of files can be recovered by merging their old state
+  with their current state.
+* Recovering an old version of a file does not erase the intervening
+  changes.
+* `svn revert` undoes local changes to files.
+* `svn merge` merges two revisions of a file.
+
+Setting up a repository
+=======================
+
+Key points
+----------
+
+* `svnadmin create $NAME` creates a new repository.
+
+Provenance
+==========
+
+Key points
+----------
+
+* `$Keyword: …$` in a file can be filled in with a property value each
+  time the file is committed.
+* `svn propset svn:keywords $PROPERTY $FILES` tells Subversion to
+  start filling in property values.
diff --git a/version-control/svn/instructor.md b/version-control/svn/instructor.md
new file mode 100644 (file)
index 0000000..45a0b0b
--- /dev/null
@@ -0,0 +1,36 @@
+In addition to the generic version control notes.
+
+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.)
+
+Teaching notes
+--------------
+
+* 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.
+
+* 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.