TOS Chapter 4

This chapter covers source control management (SCM) tools and how to use them, specifically teaching you how to use Subversion.


Exercise 4.2.1 - Installing Subversion
I was first introduced to Subversion last semester when Dr. Bowring had us use it as a way to communicate with our team members and keep our projects updated.  I can honestly say that I wish we had read this introduction last semester because we had to learn how to use it on our own, and it can be a bit confusing at first.  I think it took me a little over a month to finally get the hang of Subversion once I figured everything out all the features I had to use.


The first step is to "check out" a working copy of the code you want to work on.  This basically means you're going to ask Subversion through a series of commands to download a copy of the code to your computer, that way you'll be able to look through it and make corrections/additions to the copy of the code that you have without having to worry about messing up the code that's already out there.


Exercise 4.4.1 - Initial Checkout of the Sample Codebase
Subversion claims that it can't checkout the code I'm supposed to get for this exercise, saying "Host not found".  Well, that's not good. 


As this chapter explains, there's a work cycle that normally takes place when using SVN:
Update your working copy
--> svn update
Make changes
--> svn add
--> svn delete
--> svn copy
--> svn move
Examine your changes
--> svn status
--> svn diff
Possibly undo some changes
--> svn revert
Resolve conflicts (merge others' changes)
--> svn update
--> svn resolved
Commit your changes
--> svn commit
This cycle is basically what you do every day, minus using all the fancy tools that Subverison offers.


Exercise 4.5.1 - Update your Working Copy
I can't do this exercise because I can't get a working copy checked out to my Subversion.


Making changes to your code isn't hard to get the hang of.  It's similar to making patches.  You can do file changes or tree changes.  File changes can be made with a text editor, and Subversion automatically checks for which files have had changes made, and it also handles binary files as well as text files.  Tree changes can be made by asking Subversion to mark files/directories scheduled for removal, addition, copying or moving.  These changes might take place immediately in your working copy, but they won't show up in the code in the repository until you've committed them.  There are 5 Subversion commands that are normally used when making tree changes: svn add foo, svn delete foo, svn copy foo bar, svn move foo bar, and svn mkdir blort.


Exercise 4.6.1 - Create a Biography File and Add it to the Local Repository
Once again, I can't do the exercise because of the problem I had getting the code checked out.


To take an overall look at any changes you make in the code, use the svn status command.  This command will detect all file and tree changes made to the code if you use it with no arguments.  Using the command with a specific path will show changes made only to that particular item.  svn status -u will predict conflicts between files.  The svn diff command will do the same thing, just the shorter version.


But what if you decide you don't like the changes you made to a file, or you accidentally deleted a file?  Never fear, my friends, for all you have to do is use the svn revert command.  This command will revert the file to its pre-modified state (i.e., what it was before you messed with it).  Pretty nifty!!


If you're making changes and you update and get a "C" next to your file, well then you've got a conflict.  Conflicts mean that changes in the server overlapped with your own.  Every time a conflict occurs, Subversion will do 3 things:
1.  Print C during the update, remembering that the file is in a state of conflict.
2.  If Subversion thinks that the file is manageable, it will place special conflict markers that delimit the sides of the conflict into the file to visibly demonstrate the overlapping areas.
3.  For every conflicted copy, Subversion places 3 extra unversioned files in your working copy: filename.mine (your file as it existed in the working copy before the update and without conflict markers, and isn't created if the file isn't considered to be manageable); filename.rOLDREV (the file that was the BASE revision before the update, i.e. the file you checked out before you made the edits, with OLDREV being the revision number of the file in your repository); and filename.rNEWREV (the file your Subversion client just received from the server when you updated your copy, and it corresponds to the HEAD revision of the repository, with NEWREV being the revision number of the repository HEAD).
If you experience any confusion when this happens, just consult these 3 files to get it straightened out.  You can also copy one of the temp files created by Subversion into your working copy if you want to get rid of the changes you made,  or just revert them if you decided to scrap what you've done and start over.


Once you've made your changes, done updates and resolved any conflicts that came up, and all systems are go, then it's time to commit your work! Just use the svn commit to send all of your changes to the repository.  You add a log message to it by putting -m at the end of the command, or use -F to pass the file name of the message you want to put with it.


Exercise4.11.1 - Commit Code to the Repository
Can't do it, Subversion still being uncooperative.


Well, I pictured that going a bit differently, but still an informative reading!