Subversion Hotsheet

Using Subversion for WWP website

Setup

We have multiple working copies of a single repository. The repository itself is at https://svn.brown.edu/svn/stg/wwp/website/trunk/. You can actually access it using that URL in a browser, albeit read-only via a very limited web interface.

The more important working copies are at:

• live website papa:/var/www/htdocs/WWP/
• development website golf:/var/www/htdocs/WWP/
• Syd's work desktop: Pradoel:/Users/syd/Documents/WWPweb/
• Jacque & Julia's work desktops.

What has changed?

To find the difference between a working directory and the repository, use the "svn status" command with the "-u" switch. One way to do so:

1. Log in via a commandline interface
2. cd to the working copy
3. issue svn stat -u

The output will be a list of all files (including those in subdirectories) for which the file in the repository and the file in the working copy don't match. In front of each file's name will be its revision number and up to 5 flag fields indicating a variety of attributes about the file's current condition. By far the most common and most important are:

svn st -u code	meaning
M	local version has been modified (needs to be committed)
*	repository version is newer than local (need to update local)
?	file exists in local working copy, is not in repository (needs to be added)

Note that a file can have both the M and * markers, which may be OK, but may also be a Bad Thing?. (See description of "G" and "C" in next section.) For a list of what other flags mean (if & when you see any others), issue svn help stat.

"Downloading"

To copy files that are newer in the repository (i.e., those marked with "*") into the working directory:

1. Log in via a commandline interface
2. cd to the working copy
3. issue svn up

The output will be a list of all files that get modified in the working copy. Each will be preceded by a code letter:

svn up code	meaning
A}	Added: file did not exist in working copy before, and was downloaded from repository
D	Deleted: file was in working copy, but was deleted to match repository
U	Updated: file's content was changed to match that which is in the repository
G	Merged: same as above, except that the local working copy of this file already had (and still has) modifications as compared to the repository
C	Conflict: Subversion was unable to update file due to conflicting local modifcations, human must resolve

The first three are benign, just indicating that what you wanted to have happen happened. The "G" code indicates that subversion has successfully updated a file that had local modifications: none of the changes in the repository directly conflicted with any changes you made locally. The local working copy has both sets of changes in it. (The repository copy has not received your modifications, though; see next section.) The dreaded "C" code indicates that there was a conflict: since the file was last copied from the repository to the working copy it has changed in the same part of the file in both places (repository & local). A human must resolve the conflicts. Ask Syd or read the [book].

"Uploading"

To send the changes you've made to the local working copy to the repository issue svn commit -m "useful message". Note that while the message is associated with the entire directory, it is not generally necessary to name the file(s) you changed, as the subversion commands that list the commit messages can tell you which files were changed. If you forget the -m switch, subversion will launch an editor for you to enter a message.

Quick-edit sequence

To fix a quick typo directly on the live website:

1. Log in to papa via a commandline interface
2. cd /var/www/htdocs/WWP/
3. svn stat \-u
4. svn up}}, unless there is nothing to be updated or something looks amiss
5. correct typo (may well use a remote editor, e.g. BBEdit on your Mac using sftp to edit the file)
6. svn commit \-m "clever message"

Development sequence

At the moment, we are treating the production website as just another working copy. Thus changes should not be committed unless they are ready to go on the website, as someone else could issue svn up from the production website at any time.

1. Log in via a commandline interface
2. cd to the working copy
3. svn stat -u
4. svn up, unless there is nothing to be updated or something looks amiss
5. (Note that you can work on as many files as you want or need to.)
   • edit files (may well use a remote editor, e.g. BBEdit on your Mac using sftp to edit the file)
   • to delete a file issue svn delete file
   • to add a file, create it as you normally would with your editor, then issue svn add file
   • to rename a file, issue svn ren old new; IIRC the file still has the old name until you commit
6. svn commit -m "clever message"

Note that none of the changes (edits, additions, deletions, renamings) will occur in the repository until you issue svn commit; some of them may not even happen locally until you commit. Furthermore, either all changes are successfully transmitted to the repository or no changes are committed.