Great! I knew you would. Let’s go over it.
Version control is absolutely essential in modern coding, especially when working in groups or working on rather large code bases.
So what is version control exactly?
Version control is a tool designed to keep a software system well organized through many development cycles, bug fixes, and feature iterations. It keeps a history of all the changes you’ve made to the code on a separate server. This is useful for several reasons:
rm -Rf < dir >? Linux has no way of undoing that. With version control, that’s not an issue
But it’s more than just an external backup tool. Imagine you thought you were doing a wonderful fix, and five hours in your realize this added a far more horrific bug, and you just want to undo it all? No problem! Version control has the entire history so you can revert the project to any of its past states.
Let’s go over a brief tutorial of version control.
To create a new repository, you do
svn checkout < url path > or
svn co < url path> if
checkout is too long. So for me, it would be
svn co https://svn.cs.dartmouth.edu/classes/cs50-S12/chander/lab2. It will ask you for your username and password - should you not know them, speak with the sysadmin (Wayne Cripps).
Great, now start coding as normal. How often should you save to SVN? As often as you save a file! But if that’s too much work, remember this rule of thumb: whenever you make any significant changes, you should upload them to SVN. This will save you many headaches in the future.
So let’s fast-forward half an hour and you think you’ve finished a large portion of the first part of the lab. Great. How do we commit the changes to SVN?
svn status will give you a synopsis of all changes that are not committed to the SVN server. If you see something like
A README.txt, it means you’ve added a new file. To add it, simply execute
svn add README.txt. Conversely, if you see
D README.txt, it means you’ve deleted it. If you really want to delete it, type
svn rm README.txt.
Once you’re done with the changes, commit them to the server with
svn commit -m " A descriptive message explaining changes so you can find them later ".
And you’re done! It’s committed. To see all past commits, execute
One critical thing to remember is that every time you go to your svn repo (repository), execute
svn update before you start any coding. This is particularly important in group projects. Imagine you’re in a group of three people. You make some changes, and you upload them to the server. Then, without updating, your friend makes changes on his local repo and tries to upload them to the server… Well, his copy was out of date! This is what’s called a conflict.
There’s an entire tutorial on resolving svn conflicts, which can sometimes be quite complicated. It’s much better to avoid them entirely. So make sure you
svn update before you do any
svn commit -m’s.
Some instructions regarding spy.sh:
Our section server is moose. If you are visiting this page from another section, please note down which server your section will be using:
Substitute < server > for whichever your section’s server is, and
Login to < server > using
ssh < username >@< server >.cs.dartmouth.edu
Run only one spy.sh at a time during the debug phase. Kill it when you don’t need it. See “How do I kill my spy deamon?” in the lab notes.
Mail “Andrew Campbell” and “< section leader >” in your spy.sh.
Change of the Important Note:
Important: Professor Campbell and I will each log on to < server > (important) a number of times on Sunday until 10 PM - we’ll sneak on, and your mission if you accept it is to take us down.
To allow you to test your script Andrew and I will sneak onto < server > on Saturday, too. I will post what we did on Saturday to see if you caught us so you can more accurately test your code.
Just after 10 PM Sunday send an e-mail to Andrew and the section leaders that lists the following:
Dear Sneaky cs50 Guys:
Caught you sneaking on to sabattus today. Here’s a summary of my surveillance:
Professor Campbell, you logged on N times for a total period of X. Here is the breakdown: 1) Logged on Sat Jan 12 18:40:34 EST 2008; logged off Sat Jan 12 18:40:34 EST 2008
< Section leader >, you logged on Z times for a total period of X. Here is the breakdown:
1) Logged on Sat Jan 12 18:40:34 EST 2008; logged off Sat Jan 12 18:40:34 EST 2008
Professor Campbell or < section leader > the spent most time on
Professor Campbell or <section leader> was on for the shortest session for a period
of Y’ mins, and therefore the most sneaky; and,
Andrew or < section leader > logged on the longest session of 15 mins.
(Note that three variables need to be maintained by spy to be able to correctly fill in the paragraph above correctly – i.e., Andrew OR < section leader >. This is a note and should not be included in the email.)
Thought you could sneak by my code hey - nailed you.
Please test the spy.sh on your section’s machine.
How do I do bash?
You have sufficient resources for this - the lectures, your terminal, and this handy tutorial.
Good luck on lab 2! Start early,
spy.sh is no pushover, especially if you are new to bash.