From: W. Trevor King Date: Wed, 23 Oct 2013 04:09:19 +0000 (-0700) Subject: version-control/svn: Remove SVN-specific content X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=e287189e9ac0e7be3dc0140f60ee25321082a60a;p=swc-boot-camp.git version-control/svn: Remove SVN-specific content This branch is only interested in motivating version control and providing generic information about it. Tool-specific information is contained in tool-specific branches. --- diff --git a/version-control/svn/README.md b/version-control/svn/README.md deleted file mode 100644 index 3131911..0000000 --- a/version-control/svn/README.md +++ /dev/null @@ -1,77 +0,0 @@ -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 things` 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 deleted file mode 100644 index 45a0b0b..0000000 --- a/version-control/svn/instructor.md +++ /dev/null @@ -1,36 +0,0 @@ -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.