information.
* Check out a working copy of a repository.
* View the history of changes to a project.
-* Explain why working copies of different projects should not overlap.
* Add files to a project.
-* Commit changes made to a working copy to a repository.
-* Update a working copy to get changes from the repository.
-* Compare the current state of a working copy to the last update from
- the repository, and to the current state of the repository.
+* 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.
-* The master copy is stored in a repository.
-* Nobody ever edits the master directory: instead, each person edits a
- local working copy.
-* People share changes by committing them to the master or updating
- their local copy from the master.
+* 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 forcing them to merge concurrent changes before
- committing.
+ 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.
-* Working copies of different repositories may not overlap.
-* Each changed to the master copy is identified by a unique revision
- number.
+* 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.
-* 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
=================
* Explain what causes conflicts to occur and how to tell when one has
occurred.
* Resolve a conflict.
-* Identify the auxiliary files created when a conflict occurs.
Key points
----------
* Conflicts must be resolved before a commit can be completed.
-* Subversion puts markers in text files to show regions of conflict.
-* 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.
+* Most version control systems put markers in text files to show
+ regions of conflict.
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
+* Recovering an old version of a file may not erase the intervening
changes.
* Use branches to support parallel independent development.
-* `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.
* Repositories can be hosted locally, on local (departmental) servers,
on hosting services, or on their owners' own domains.
Key points
----------
-* `$Keyword: …$` in a file can be filled in with a property value each
- time the file is committed.
* Put version numbers in programs' output to establish provenance for
data.
-* `svn propset svn:keywords $PROPERTY $FILES` tells Subversion to
- start filling in property values.
projects / swc-version-control-svn.git / blobdiff