Getting Started – Repository

The assignments for the ACC course will be managed by the git versioning system. You will find this enables you to easily save progress, go back in time, collaborate (with your group colleague!) and try out different versions of the assignment with ease. It will also allow you to mark commits as final deliverables for the assignment and run the test suite on them remotely.

Creating a group for yourself and a colleague

In order to have access to the assignments you need to decide on a colleague to team up with and announce it to the TA. The TA will then create a user for you in the Repository (see also link in the right-hand menu). Now you can log into the interface and upload your ssh key, which you can obtain by doing:

 $ if [ ! -f ~/.ssh/id_rsa.pub ]; then echo "" | DISPLAY="" ssh-keygen -t rsa; fi;  $ echo "8<---"; cat ~/.ssh/id_rsa.pub; echo "8<---" 8<--- ssh-rsa XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX me@mycomputer 8<--- 

Now you take the key (between the two cut marks) and paste it into the Keys tab of the repository:

The "Keys" page in the Repository application

Now, you should be able to access the repository. Go to the “Repository” page and under URI you should see your group ID and the reposiotry URL:

The "Repository" page in the Repository application

Now, from the bottom of the page, you have the URI of the repository:

 [email protected]:acc2013-groupXX 

You can use this URI to clone the repository, which will be described in the next chapter: Git crash course.

Git crash course

There are many great git tutorials on the Internet, but in this section we’ll go through a series of common commands, so we’re all on the same page. Feel free to skim through this section or completely skip it. The next sections are important, though.

To get the compiler code on our computer we have to clone the repository, which is already populated with the l3 compiler code for the first assignment. You will get the source code for the compiler frontend:

 $ git clone [email protected]:acc2013-groupXX # replace XX by your group number! $ cd acc2013-groupXX 

This should place a acc2013-groupXX directory. If you look in that directory, you will find the l3 compiler in l3/compiler. Now let’s modify a file:

 $ echo "I MESSED UP THE README FILE" > l3/README

Congratulations, now you messed up the README file in the repository! Let’s make sure this is so:

 $ git diff diff --git a/l3/README b/l3/README index 429adf7..87a3393 100644 --- a/l3/README +++ b/l3/README @@ -1,27 +1 @@ -The L3 compiler and virtual machine project -------------------------------------------- ... 

Okay so we modified a file. What now?

 $ git status # On branch master # Changes not staged for commit: #   (use "git add <file>..." to update what will be committed) #   (use "git checkout -- <file>..." to discard changes in working directory) # #    modified:   l3/README # no changes added to commit (use "git add" and/or "git commit -a") 

So, we have git add <file> to put the change in the commit, and git checkout — <file> to revert our changes. Let’s go on and commit the change:

 $ git add l3/README [master bac3429] Update README  1 file changed, 1 insertion(+), 27 deletions(-)  rewrite l3/README (100%) $ git commit --message="Updated README file"

or

 $ git commit --all --message="Updated README file" [master 09d4672] Update README  1 file changed, 1 insertion(+), 27 deletions(-)  rewrite l3/README (100%)

The two commits do exactly the same thing, commit the new readme file locally. The difference comes from the control you get by using git add <file>. You can only commit some of the changes, not necessarily all of them. What’s a local commit you ask? Git is distributed, and each “clone” of the repository can have it’s own history. Sometimes you’ll want to synchronize them, so the Repository application can see your code changes. In that case, you can use git push:

 $ git push origin master

Where origin is the repository you cloned (that is stored on larasrv05.epfl.ch) and master is the main branch that is created by default. The opposite of pushing to a repository you cloned is called pulling:

 $ git pull origin master From larasrv05.epfl.ch:acc2013-group01  * branch            master     -> FETCH_HEAD Already up-to-date. 

Using git push and git pull also enables synchronizing in a team, with the central repository being stored on larasrv05.epfl.ch.

If you followed the tutorial closely, you will noticed you actually rewrote your README file and commited it. Did you get a chance to read it before? If not:

 $ git revert HEAD [master 9bd5082] Revert "Update README"  1 file changed, 27 insertions(+), 1 deletion(-)  rewrite l3/README (100%) $ git push origin master .. 

A note about rewriting history (aka git push -f). Don’t. Really. Don’t. Use git revert. Even if you rewrite history, the commit will still be on the server, but it will be harder to get to. More work to get your deliverable, less points for your assignment. So don’t rewrite git history if you’re touching commits marked as deliverables.

Marking as deliverables and running tests

Once you pushed your change, it should be visible on the Repository web application. Once you have all the changes required by the assignment, you can mark a commit as being the “Deliverable” for one of the assignments. When the deadline expires, having a commit marked as “Deliverable” will mean it should be graded even if there are other commits on top of it. So keep it up to date.

The "Deliverables" page in the Repository application

Another reason to keep the “Deliverable” marker on the last commit is that you can run a small pre-written test suite on that commit by clicking on “Schedule tests“. The tests aim at catching the common mistakes in the assignment, but will be nowhere near exhaustive. So even if your commit passes all tests or fails a couple, the grade will still be given manually, based on the quality of your work.

You can mark as deliverable and run the tests as many times as you wish. Its sole purpose is to enable you to submit good code. And since just iterating many times through the test is not really challenging, the tests we run will be hidden: you will only be able to see the name of the test, but not the actual code we’re compiling and running. You will still need to give it some thought on why exactly is the test failing.

Also, you’re encouraged to write your own test suite to check your implementation, especially since you’ll have the testing infrastructure already in place — there’s only the cost of writing actual tests. And a good implementation with good tests is more likely to get full points than a good implementation without tests.

Questions on the Assignments

Finally, questions regarding the should be addressed to the TA during the displayed office hours or on Moodle forums. You should register for the Moodle forums already, as usually discussions there are very useful for everyone.