The Australian National University   Research School of Computer Science

COMP2100/2500/6442 Software Construction

in 2013

Lab 1: Using SVN and the personal Developer's Log

$Revision: 1208 $ $Date: 2013-02-21 16:28:25 +1100 (Thu, 21 Feb 2013) $

Summary

An introduction to using SVN Subversion Version Control System to share development of a program in a group, and then an exercise in using the Developer's Log process to record development time and defects. Includes some work in a small group to demonstrate the shared repository of SVN.

Aims

In order of importance:

• Give you a first experience of using Subversion for version control.

• Give you some practice following the developer's log process and filling in the forms.

• Refresh your Java programming skills.

Preparation

Read through the course notes for Subversion Version Control System.
Note in particular the recommended repeated working cycle of

1. svn update;
2. edit, develop and test; and
3. svn commit

For the second part of the lab, review the Developer's Log Rationale
and bookmark the links to the Log Template (in whatever format you want to use) and the List of Defect Types.

Exercise 1

Using Subversion in group work.
For this lab you must use the command line window (terminal).
Access on the student labs desktop: Applications –> Accessories –> Terminal

1. Open a terminal window to use commands. This lab is a lightweight is an introduction to using the command line, you'll learn more about the command line and the shell later this semester.

2. Find the other members of your team for lab1.

   The team is listed in the file /dept/dcs/comp2100/public/lab1groups.txt.
   also available at http://cs.anu.edu.au/student/comp2100/labs/lab1groups.txt.

   Use the command % grep $USER /dept/dcs/comp2100/public/lab1groups.txt to find the user ids of the other people in your group. (The "%" is not part of what you type for the command, it just indicates the command line prompt, whatever it is.)
   The $USER here is a shell variable that is automatically replaced by your own userID, which is why this command finds the line of the file that contains your UID.
   Write down your group name and go find the rest of your group—change workstations to sit together.

3. When you are sitting near each other:

4. You must clean out your Ubuntu/KDE keyring so that svn security passwords work.

   The cleaning up instructions are in a separate file cleanKeyring.html

5. Each person then creates a project for this lab in your own directory. Here's what to do.
   If you have a comp2100 directory in your home, change directory into it using the command % cd comp2100 otherwise create that directory: % mkdir comp2100 first, then change directory into it.
   Create a directory for your labs % mkdir labs and under that, a directory for this lab:

     % mkdir labs/lab1

   Change to this directory for your work: % cd labs/lab1

   The cd command changes the working directory as the environment where any following commands are executed.

   If you want a more graphical view of what you have done, look at these directories with the file and directory explorer viewer application.

6. In this directory (your ~/comp2100/lab1 check out a working copy of your group's shared program from the repository that I have provided as an initial template. It is called Intro2Group.java

       % svn checkout https://svn.anu.edu.au/SWConstr/lab1/branches/gDayN
   

   where gDayN is actually your group number, such as gWed42

   VERY IMPORTANT: note the use of https here, not http. It makes a difference if you work off campus.

   This creates a directory named for your group gDayN in your current working directory. This directory is an SVN project that is tied back to the SVN respository. Change your shell into it:

     % cd gDayN

   and look at the files

     % ls 

   and look at these files SVN relationship and status

     % svn info
     % svn status -v
     % svn log
   

7. Now start using the file in cooperation with the rest of your team.

   The aim is for you to change the file so that it prints out the long and short names of all of the team members, in alphabetical order of family names. Use a text editor like emacs or kate (later you will use eclipse but for now, it does not interact easily with subversion - please stick with the simple text editors for this exercise).
   Use the svn commands svn update, svn log and svn commit repeatedly while you edit and test the program. Do this as fast as you can! Team members can work simultaneously, and don't talk more than you have to to fix misunderstandings. Subversion will look after you. Using subversion you will get the updates made by other members of the team.
   To compile the program use

     % javac Intro2Group.java

   To run the program use

     % java Intro2Group

8. When all members of the team have a working copy that is finished and prints out the names of all the team members, that's completed part 1. Have a short break from the computer.

   Reflection and discussion time: talk with your team members, share experience on how you saw conflicts and how you resolved them without losing any work, and what happened when you forgot to update. The purpose is for each of you to understand what to do for the course assignments when you do more program development in a small team under version control.

Pause to reflect

In future you will probably want to add directories of your own to the repository for homework exercises and perhaps for the other labs. You can do this with

  % svn mkdir  newdirectoryname

and then you will use

  % svn add 

to add files that you have created, or connect projects from eclipse usoing the eclipse pull own menus.
Your assignment work will use a different repository with a trunk that can be read by the whole class, with a branch for each team. That way you can share your work with your partner securely. This is one of the biggest strengths of using version control.

You can also set up space in your personal repository for any computer-based work you do that is important enough to want to keep track of changes and have good backups. Just add more directories to the repository as you need them.

The other good thing about this way of working is that you can work from home, from a friend's computer in Sydney, from the machines in the labs, easily keeping your work synchronised. Just make sure that when you finish working in one location you “svn commit” all your changes, and that when you start working in the next location you “svn update” to get the latest version.

Exercise 2: Program development with personal Developer's Log and your personal SVN repository

This time you work alone not in the team, but consult team members for help in this work.

A directory and program template have been setup in the SVN repository for each student. In your labs/lab1 directory (cd ~/labs/lab1) checkout a working copy

  % svn checkout https://svn.anu.edu.au/SWConstr/lab1/branches/uNNNNN    mylab1

This directory already contained an existing source program called Year.java of which you now have a working copy. Make a small change to the program: add your name as an author. Compile and test. Check status! what files are under vrersion control? changed (modified)? not under version control? Commit your changes to the source file.

Exercise 3: do a simple development using the Developer's Log

Modify a given program to solve the problem below, filling in a page of Developer's Log with an estimate of the program size, the time you are taking, and Defect Recording as you go. Read through all the instructions below before you start.

Read through the task instructions before you start programming.

The objective is to extend the Java class Year, intended to be part of a date and time library. This class must have the following features:

1. A private field called value of type int in which the number of the year will be stored.

2. An accessor method called getValue() that returns the value of value.

3. A function called isLeapYear() returning a boolean which returns true if the year is a leap year and false otherwise.

4. A constructor that takes a single argument of type int, and sets value equal to the value of that argument.

5. A main() method, used for testing the class, that takes any number of integer values given on the command line as arguments. For each one it creates an instance of Year with the value it has read, and then uses the result of a call to isLeapYear() to print a message.

The rule for leap years in the modern Western (Gregorian) calendar: a year is a leap year if it is evenly divisible by 4, but not divisible by 100; unless it is also divisible by 400. For example: 2000 is a leap year (divides by 400); 1900 is not; 2008 is a leap year.

The Gregorian calendar was adopted in 1752 in England, so print a warning instead, for years before 1752.

Here is a sample interaction with the program. What the user typed is in blue, system output is in black.

[comp2100@partch]$ java Year 2004 2005 1751
Yes, 2004 is a leap year
No, 2005 is not a leap year
1751 is out of range (before 1752) for the Gregorian calendar in the English-speaking world.

Additional task

If you have completed the task and done the PSP work, here's a more realistic task as an extender.
Add a pop-up dialog to ask the user for the years, instead of using the console for input and output. This time you should include estimated "research" time in the Design phase (research: looking up details or examples in the Java library, or finding a reference example that you can use as a base).

Developer's Log Notes

Make an initial estimate of the size of the program you will need, in lines and in numbers of methods and any supporting classes. Make a sketch of the design: discuss your ideas for doing this with your team members, to make sure you haven't forgotten anything before you start coding.

you will probab;ly work in one hit: design then implement and then test and debug; or incrementally, after a general design, implement some aspect, test it, and then do some more. You may need to refactor—rewrite some major chunks—part way through as your ideas develop.

While you are working, use svn to commit changes frequently. Check the status of what you are doing with

  %  svn status -v

As you commit new versions, make sure to include comments that are meaningful in terms of your development process (don't repeat what you have changed in the code, because that's obvious in the code itself: describe the step in your solving the problem, getting your program to work, and suchlike). For example:

  % svn commit -m 'first attempt Year.java functions'
... working working working ...
  % svn commit -m 'fixed logic error in combining 100 and 400 year tests'
... working working working ...
  % svn commit -m 'passed all tests'

Compile the program from the command line by typing:

  % javac Year.java

rather than using any editor menus.

After you finish fixing each defect, commit a new version of Year.java to your repository.

In the commit comment, link this version to your Defect Log, by putting something in the comment like: “Fixes defect #17”. You might want to add a short description of what that defect was and how it was fixed. Or not.

svn commit -m 'Fixes defect #17 - using the right integer division operator' Year.java

Record the time spent.

What to test?

Here is some sample data just to make sure that you have understood the requirements.

Every time your program does something it isn't supposed to do, or gives a wrong answer, you need to record that in your Defect Log. Also note the time that you located the defect. Fix the problem, then look at the time again and enter the time taken on repairs .

As in the earlier phase, commit a new version of Year.java to the repository after each defect fix.

Postmortem

You can review your work progress using the svn log command:

  % svn log

reflect on what you have learned by doing this: places where you can improve, things you were surprisingly good at, things that should not hav gone wrong but did...

To compare your estimate of size, to get the actual program size, count the lines by hand. (or use the editor) and subtract comments and completely empty lines. Later in the semester we'll get into counting logical lines of code in a little more detail. For the moment, count all lines except:

• those that are entirely blank,

• those that have only comment delimiters (“/*” or “*/”) on them.

To make this repeatable, put only one Java statement on each line.

self improvement

Save this developer log for yourself to track your self improvement and continued areas of dificulty