Goals of today's section:
(Quiz 1 handed back)
Subversion
Motivation:
Any and all of the above are strong reasons to use a source control repository. The one I recommend you use (and the one configured for CSE 451) is subversion.
A bit of history --
Subversion is built on top of CVS.
CVS works, but has a few caveats -- does not guarantee
atomicity of transactions, more easily corrupted if things
glitch, and has different versions for each file. This is a pain.
All your files are stored on a server (in this case, the attu computer(s) are the server), in a directory called a repository (/projects/instr/06au/cse451/your_group_letter/svnrep)
The repository is the collection of files that are the ``master
copy''. But these aren't just static copies of the "latest version"
of your files. Every time you make a change to any file in the
repository, it generates a new "revision." A repository is a sequence
of these revisions. Revisions can add/move/delete/copy files, as
well as modify their internal contents. (You'll notice that
when you commit files to the repository, a successful finish will
say "Committed revision 100" or some other number.)
The most recent revision is called the head revision.
Getting started:
To get started, you'll need to check out a copy of
the repository. so execute: svn checkout
svn+ssh://attu.cs.washington.edu/projects/instr/06au/cse451/GROUP_LETTER/trunk
any_subdir_name
This will create a working copy of the repository
in its most recent state, in the subdir you've chosen. You will
modify your working copy, then commit changes back to the
master repository. You can also update your working copy,
so that changes to the repository made by other users are reflected
in your copy.
Important note: You may be concerned that if somebody else updates the same file you're working on, your changes will be overwritten. You will never lose your own data -- subversion will not update changes "on top" of your modifications. This is called a conflict; I'll explain below.
Some really basic commands:
svn add filename -- adds a file to the repository.
svn del filename -- removes a file from all future revisions
of the repository, and from the local file system (though you can
always grab an older copy from the repository, later)
svn update [dirname] -- will update your working copy to
the head repository revision.
svn commit [dirname/filename] -m "message here" -- commits
local changes to the repository.
When committing, you must include a message, detailing what you've changed. This history is made available to other users to browse, if they'd like. If you don't include a message on the command line, svn will pop up an instance of vim and make you type one in. If you don't give a message, svn will abort the transaction.
What happens if two people edit the same file?
It depends. If you edit the top of the file, and I edit the bottom,
svn will be able to merge these changes. When committing,
svn will abort the commit and state that one of your files is out of
date. You must then update your copy. Your local svn will then
perform the merge, and you can commit the merged copy back to the
repository.
If you and I have both editted the same part of the file,
the file's state will be marked as conflicted. Again, you'll
need to update your local copy.
This time, subversion will mark the overlapping edits, like so:
...
this part of the file is shared between us; no conflicts here
...
<<<<<<
For this line, one user wrote one thing
----------
But another user wrote something different
>>>>>>
...
and the rest of the file's the same.
It may also give you some "full copies" of your file named filename.mine and filename.rNUM. The ".mine" will be what your file looked like, prior to the conflicts. the .rNUM file is whatever the head revision looked like, in its entirety. You can (and should) delete these files after you've resolved the changes; they're there for your reference.
You'll need to go through the file by hand, search for those
blocks, and determine which of the two different lines is
appropriate. Remove anything you don't want to be in the final
file, including the <<<, etc. Once you've unified
all the changes into one coherent document, you'll need to tell
subversion that you've done so:
svn resolved filename -- marks the file as resolved.
Then you can svn commit the file.
Rolling back to an older copy of a file:
If you have introduced a bug or something screwy, and want
to get back to a version of a file older than the current
revision, you can svn update filename -r REVSPEC.
REVSPEC can be either a revision number, or {DATE}.
In either case, it'll pull up the appropriate revision for you.
Cancelling your current changes to a file
If you've changed a file and you realize your changes are all
wrong (they introduce a weird bug, whatever), you might just want
the last copy that's in the repository.
rm filename -- to delete your own copy
svn update -- will restore the head revision copy.
Finally -- those commit messages: where do they go?
Type svn log filename, and it'll print (in reverse
order -- newest first), the log of change messages to the files.
As always, svn help is a good place to explore additional commands.
Synchronization Pitfalls