Recitation 1

Lab 1 - You DID Do It, Right?

Great! I knew you would. Let’s go over it.

Version Control!

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:

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 svn log.

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.

Lab 2

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

for whoever is your particular section’s leader..

  1. Login to < server > using ssh < username >@< server >.cs.dartmouth.edu

  2. 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.

  3. 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.

Extra Credit

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

2) …

< 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

2) ..

3) ..

Looks like Professor Campbell or < section leader > the spent most time on today - X’ mins in total for all his sessions; 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.

Best,

Your name

Please test the spy.sh on your section’s machine.

Bash Scripting

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.