[FrontPage] [TitleIndex] [WordIndex

Note: You are looking at a static copy of the former PineWiki site, used for class notes by James Aspnes from 2003 to 2012. Many mathematical formulas are broken, and there are likely to be other bugs as well. These will most likely not be fixed. You may be able to find more up-to-date versions of some of these notes at http://www.cs.yale.edu/homes/aspnes/#classes.

These are very sketchy notes on using Subversion for CS422 students. For more details see the Subversion web site at http://subversion.tigris.org or the online book Version Control with Subversion.

1. Basic concepts

Subversion is a centralized Distributed_version_control_system, which in this context is a fancy way to say a distributed file system with versioning. Files are stored in a repository, which is either a local directory accessible to the user or on a server somewhere. To use the files, you need to check out a local working copy that you can tinker with. When you are done, you commit your changes back to the repository, supplying a log message so that other users who may be sharing the same files will know what you did.

2. Subversion commands: basics

All Subversion commands go through the svn executable. Type svn help for a list.

Typical use of Subversion involves only three commands: svn co to get the initial working copy, svn up to pull changes from the repository, and svn commit to put your changes back.

2.1. svn co [url]

Check out a working copy from the given URL. This will create a copy of the most recent version in the repository under the current working directory.

Example: svn co http://pine.cs.yale.edu/422/user/some-user-name creates a new directory some-user-name in the current directory. If the repository is password-protected, you may need to supply a username and password for this to work. You can also access some repositories directly through a web browser (but you will generally not be able to commit changes or get at past history).

2.2. svn up

Bring the current working copy up-to-date, incorporating (by merging) any changes that were made in the repository. Any local changes will not be lost; instead, Subversion will attempt to merge non-overlapping changes together. If it fails, you will have to clean up after it (see svn resolved below); this should only happen if somebody else commits a change since the last time you did.

2.3. svn commit

After changing something, you can put your changes back with svn commit. This will pop up your default editor to write a log message. If you want to avoid dealing with the editor, you can supply a message on the command line with the -m switch, e.g. svn commit -m "fixed life-threatening scratch monkey remount bug".

3. Getting information

3.1. svn log

Prints all log entries touching the current directory to stdout.

3.2. svn status

Tells you what files in your working copy are modified, what files are unknown, etc., what files have unresolved conflicts, etc.

3.3. svn diff

Tells you the difference between your working copy and the checked-in version. Can also be used with the -r or -D switches to get differences between the working copy and older revisions, e.g. svn diff -r1031 or svn diff -D yesterday. Can also be used on individual files: svn diff broken.c.

3.4. svn cat

Send a copy of a file to stdout. Mostly useful with -r or -D: svn cat -D 2006-05-01 may-day-parade-schedule.txt is the best way to recover an old version of some file. (Don't be tempted to use svn up for this, despite what the documentation says: you will get your working copy stuck in some ancient state.)

4. File operations

Subversion doesn't pay attention to files unless you tell it to, and for this reason any changes you make that go beyond editing files Subversion already knows about require you to tell Subversion about them.

Note: You should not add any files to the repository that can be regenerated automatically (e.g. binaries). Not only will this take up a lot of space in the repository, but it will also lead to confusion later when make refuses to rebuild some file because svn up already gave you a "new" copy.

4.1. svn add [file]

Tell Subversion to track some new file it wasn't tracking before. Also works on directories (it adds all contents recursively).

4.2. svn mkdir [directory]

Like mkdir dir; svn add dir.

4.3. svn rm [file]

Tell Subversion to delete a file. For reasons that are not at all obvious, Subversion insists that you delete the file yourself before calling svn rm; the fix to this is to use the -f switch, e.g. svn rm -f annoying-extra-file. Also works on directories.

4.4. svn cp [source] [destination]

Like stock cp, only does an svn add on destination for you. Also copies log information, so that the new file inherits the version history of the old. This is cheaper for the repository than copying the file yourself, because it stores only the changes (if any) between the two copies rather than both copies.

4.5. svn mv [source] [destination]

Pretty much equivalent to svn cp source destination; svn rm -f source.

Note that if you want to move a file on top of another one, you have to delete the target (using svn rm) and commit the change (using svn commit) first.

5. Fixing things

5.1. svn revert [file]

If you screw up editing something, you can throw away your changes with svn revert, e.g. svn revert broken-file. Be careful with this.

5.2. svn resolved [file]

If a merge fails, you will get a file that looks something like this:

This is my file.

<<<<<<< .mine
This is a change in my working copy.
This is an incompatible change somebody else made.
>>>>>>> .r6258

This is the rest of my file.

There will also be several extra copies of the broken file corresponding to the various versions Subversion tried to merge together. Fire up your editor, fix the file, and tell Subversion you did so using svn resolved filename. This will clean up all the extra files and let you run svn commit again. (Hopefully you will not need to use this command much.)


2014-06-17 11:58