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.
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.
Read through the course notes for
Subversion Version Control System.
Note in particular the recommended repeated working cycle of
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.
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
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.
Find the other members of your team for lab1.
The team is listed in the file
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.)
$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.
When you are sitting near each other:
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/lab1Change to this directory for your work:
% cd labs/lab1
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.
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
% svn checkout https://svn.anu.edu.au/SWConstr/lab1/branches/gDayNwhere
gDayNis actually your group number, such as
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 gDayNand look at the files
% lsand look at these files SVN relationship and status
% svn info % svn status -v % svn log
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
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 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.javaTo run the program use
% java Intro2Group
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.
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 newdirectorynameand then you will use% svn addto add files that you have created, or connect projects from
eclipseusoing 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.
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 time uNNNNNN is your student id.) Note that you have created a working copy with a different name from the original. Yours is called "mylab1" but it is connected to the repository SWConstr/labs/lab1/branches/uNNNNNN. By using a different name like this you can avoid some mixups of things which might have the same name in different places, or you can use a name which means more to you than the name in the repository.
This directory already contained an existing source program
Year.java of which you now have a working
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.
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.
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:
A private field called value of type int in which the number of the year will be stored.
An accessor method called getValue() that returns the value of value.
A function called isLeapYear() returning a boolean which returns true if the year is a leap year and false otherwise.
A constructor that takes a single argument of type int, and sets value equal to the value of that argument.
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.
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).
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.
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.
You can review your work progress using the svn log command:
% svn logNow do the rest of the personal Developer's Log process:
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.
Save this developer log for yourself to track your self improvement and continued areas of dificulty
Copyright © 2006, 2010 Ian Barnes, Chris Johnson,
The Australian National University
$Revision: 1208 $ $Date: 2013-02-21 16:28:25 +1100 (Thu, 21 Feb 2013) $ LastChangedBy: cwj $
Feedback & Queries to firstname.lastname@example.org