Motto: The palest of ink is better than the best
This page is set up to guide you through using SVN, a tool for file versioning. If you are moderately versed in SVN, you can safely skip this section.
For your project, you'll be starting from a codebase provided by us and you will modify it extensively. Oftentimes, you'll find yourself in the situation of having modified the code in ways that render it unusable (such as during that 3 am coding binge), and you'll want to return to a previous version of your code, which you know it is stable. So you want to "turn the clock back".
Also, when two students are working on the same project, you'll want to be able to make changes to files concurrently and be able to merge changes into a single codebase. Things can get rapidly out of control when using improvised tools (email, "Are you changing file X? Oops..." and so on).
On top of that, we (instructor and TA) might occasionally fix the elusive last bug in the codebase, and you'll need to merge those bug fixes with your own code that already contains your additions and changes. That might sound like magic, but it turns out there are simple line-oriented algorithms that can do a great job at merging similar text from various sources. A robust tool implementing such algorithms is SVN, the SubVersionN version control system.
Here are the steps you need to take.
% ssh your_cse_username@instructional_server
% chgrpsh +cse401x
xis a placeholder for a letter that will be assigned to by your TA. Students doing joint work will share the same letter. It looks like nothing has happened, but in reality you are now a member of the group cse401x for the remainder of the session. You can check that by typing:
% groupsYou should see cse401x among your groups.
% /uns/bin/svnat the command prompt (%). You ought to see a help message. If you don't have uns in your path, you need to add :/uns/bin:/uns/share/bin to the end of your path.
You create a repository by executing the
svnadmin create SVN
command, like this:
% /uns/bin/svnadmin create /projects/instr/qtr/cse401/x(where qtr is the code for the current quarter, e.g. 07wi)
% cd temp % unzip MiniJava.zip ; rm MiniJava.zip % /uns/bin/svn import . file:///projects/instr/qtr/cse401/x -m "Initial release"The first . specifies what directory to import (i.e. the current one); the second URL specifies the location of the repository. (SVN uses URLs for most of its commands, not regular file paths.) The -m "Initial release" is a checkin message; you'll see that a lot. After importing, remove the temp directory.
% /uns/bin/svn co file:///projects/instr/qtr/cse401/x/trunk <myproj>You should get pretty much the same files that were in the zip file, in the directory <myproj> of your choosing. Make sure you include the /trunk on the repository URL, or else your checkout will not reflect the directory layout you expect!
% cd myproj % /uns/bin/svn ci -m "Added cool feature"
% /uns/bin/svn copy file:///projects/instr/qtr/cse401/x/trunk \ file:///projects/instr/qtr/cse401/x/tags/tagname \ -m "Tagging this fantastic release of my awesome project."This makes a clean backup copy of your code at the given tagname, and you can use these tags similarly to any other revision.
% cd myproj % /uns/bin/svn updateAgain, no need to specify the root directory because SVN looks it up in SVN/Root that the checkout command had created.
If you're adding new files, say "coolfeature.java", then you need to issue:
% /uns/bin/svn add coolfeature.javaThe next time you do a svn ci, your new files will be added to the repository.