From: W. Trevor King Date: Wed, 23 Oct 2013 04:07:35 +0000 (-0700) Subject: version-control: Remove subject-level documents from this SVN branch X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=72b698acd214fad02deb30eb628f62a9acfb0aeb;p=swc-boot-camp.git version-control: Remove subject-level documents from this SVN branch This branch should only contain the tool-level content specific to Subversion. --- diff --git a/version-control/README.md b/version-control/README.md deleted file mode 100644 index 6d488f9..0000000 --- a/version-control/README.md +++ /dev/null @@ -1,113 +0,0 @@ -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 deleted file mode 100644 index 94d1ba3..0000000 --- a/version-control/cheat-sheet.md +++ /dev/null @@ -1,20 +0,0 @@ -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 deleted file mode 100644 index 78f16f0..0000000 --- a/version-control/instructor.md +++ /dev/null @@ -1,30 +0,0 @@ -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.