Version Control

Section
1

P2P-Wifi-Linux-FileSharing Project

Sourceforge.net Setup

How to Setup a CVS Client

The project will be using sourceforge.net for version control. This document assumes the project members have a sourceforge account and were added to the project on sourceforge as developers. Because the project is being developed with Java, it is operating system independent. Team members may be developing in either a Unix/Linux or a Windows environment. The following links describe the procedure for setting up the necessary CVS client in either environment:

1) Windows - http://sourceforge.net/docman/display_doc.php?docid=766&group_id=1

2) Unix/Linux - http://sourceforge.net/docman/display_doc.php?docid=763&group_id=1

When setting up a CVS client, use your sourceforge login as the username and linuxwifi as the project name.

How to Setup a SSH Client

n SSH is a protocol designed to provide secure communications between hosts on the Internet. SSH clients are available for both Windows and Unix/Linux operating systems. SourceForge.net has included within this document a list of SSH clients for platforms we deal with most frequently.

n Sourceforge.net does not permit the use of FTP and TELNET protocols. FTP and TELNET are insecure, historical protocols. SSH offers greater protection from certain attacks.

n If the OS you are using does not have a SSH client installed this link will provide you with the information to install a SSH client:

1) Windows - http://www.chiark.greenend.org.uk/~sgtatham/putty/

Follow the instructions page for SSH installation. Make sure to download everything piecewise or the windows installer from the link under:

A Windows-style installer (x86 only) for everything except PuTTYtel

2) Unix/Linux - http://www.openssh.com/

Section
2

P2P-Wifi-Linux-FileSharing Project

File Storage on CVS

Types of Files

n CVS does not actually store all versions of a file in the repository. Rather, the CVS repository stores all differences between file versions. The CVS repository must be informed when it is working with binary files to avoid corrupting them. This allows the developer to view a project historically at any specified point in time.

n Four types of files will be stored in the repository: source code, makefiles, binaries, and documents.

3) Source code – These are .java text files stored at the following directory in the CVS repository:

linux-p2p-wifi / linuxwifi / src / edu / uiuc / cs / cs327 / linuxwifi /

4) Makefiles – Two text files are included for build purposes in the CVS repository. The files are CompileIt.bat and RunIt.bat. They are stored in the following directory in the CVS repository:

linux-p2p-wifi / linuxwifi /

5) Binaries – Project JXTA .jar files are stored in the CVS repository in the following directory:

linux-p2p-wifi / linuxwifi / lib

6) Documents – These are project documents which include: the vision statement, project synopsis, use cases, requirements, class diagrams, project plan, architectural document, CM document, build instructions, and the test plan.

- These files are stored at the following directory in the CVS repository:

linux-p2p-wifi / linuxwifi / docs / project_doc

Binaries Not Stored in the CVS Repository

n The P2P-Wifi-Linux-FileSharing Project uses binary Java libraries that are not stored in the project’s CVS repository.

n Each developer should install Java^TM 2 Platform, Standard Edition (J2SE^TM) v 1.4.1 in their local development environment.

n J2SE^TMv 1.4.1 can be downloaded from the following website:

http://java.sun.com/j2se/1.4.1/download.html

n J2SE^TM includes the compiler and virtual machine needed to build and run P2P-Wifi-Linux-FileSharing Project’s software.

Section
3

P2P-Wifi-Linux-FileSharing Project

Build Directions for a Particular Version of the Project

Setting Class Path Permanently for Microsoft Windows NT, 2000, and XP (Skip this step if you are using a Unix/Linux OS)

Windows users need to perform this extra step because Windows does not have the Unix concept of a Home Directory. To develop and test applications written in the Java programming language using the Windows environment, set a path and CLASSPATH so programs locate necessary classes and .jar files by doing the following:

(1) Choose Start, Settings, Control Panel, and double-click

(2) On Microsoft Windows NT, select the Environment tab; on Microsoft Windows 2000 select the Advanced tab and then Environment Variables. For windows XP, go to the start menu and not the desktop, right click on my computer, properties, advanced tab, and then the environment variables button near the bottom of the screen.
screen.

(3) Look for "Path" in the User Variables and System Variables. If you are not sure where to add the path, add it to the right end of the "Path" in the User Variables. For windows XP, under user variables or system variables, click on new. Enter variable name “PATH” and variable value as C:\j2sdk1.4.0_<version number>\bin.

A typical value for PATH is:

                           C:\j2sdk1.4.0_<version number>\bin

(4)      You should only have one bin directory for a Java SDK in the path at a time

(5)    The new path takes effect in each new Command Prompt window you open after setting the PATH variable

Compiling the Application

n Place the current version directory (i.e. linux-p2p-wifi / linuxwifi /) anywhere on the computer where the Java SDK is located and the classpath has been set (refer to part 1 of this Section for directions on setting classpath in Windows)

n From within the “code/version” directory:

1) To compile double click “compileIt.bat”

2) To run double click “runIt.bat”

Section
4

P2P-Wifi-Linux-FileSharing Project

Checkout and Commit

Checkout the Latest Version of the Project

n This step assumes that you have properly configured your SSH client.

n Make sure your local environment variable CSV_RSH is set to ssh.

1) Windows – You should be able to set this variable within the GUI CVS Client.

2) Unix/Linux – This is done on most Unix systems by typing :

export CVS_RSH=ssh

n SSH into your sourceforge use account on the CVS server. This will create your home directory so that you can begin to use CVS. CVS will not work until you have completed this step. For more detailed instructions on setting up you home directory see: http://sourceforge.net/docman/display_doc.php?docid=768&group_id=1 - develhomedir

n To checkout latest version type the following from the cvs command line:

cvs -z3 -d:ext:<loginname>@cvs.sourceforge.net:/cvsroot/linux-p2p-wifi co <module>

- Make appropriate substitutions for loginname and module. To check out the entire directory structure you should use “linuxwifi” as the module.

n After initial checkout, you can change into this directory and execute cvs commands without the -d tag .

For example:
cvs update
cvs commit -m "comments for this commit"
cvs add myfile.c (must use the –kb option for binary files)

cvs tag "tag Name" file/directory (apply a tag to a file or directory, tags allow for a versioning schema as described below)
cvs status -v "file/drectory" (view summary of this files tags and revisions)
cvs tag -b "Branch Name" (creates a new branch in the repository)
cvs update -r "Branch Name" (switches working version to the branch)
cvs checkout -r "Branch Name" (checkout a branch from the repository)

n See a CVS manual for further commands such as merging and conflict resolution.

Committing Your Changes to the CVS Repository

n After your working copy of the system has passed all unit and system test, you may update the repository with your code.

n First tag your files with the current version according to the versioning schema below
$cvs tag "tag Name" file/directory

1) The tag command allows you to assign a version that is independent to the revision numbers internally generated by CVS.

2) This comment is stored with the changes in the CVS repository.

n Enter the following at the cvs prompt to send all changes made to the system to the repository:

$ cvs commit -m “fixed bug 1.2”

1) The –m flag designates the “fixed bug 1.2 “ comment to explain your changes to the system.

2) This comment is stored with the changes in the CVS repository. This provides an audit trail of why modifications to code were done.

n Enter the following at the cvs prompt to send changes made to one file to the repository:

$ cvs commit -m “fixed bug 1.3” guiAPI.java

n To verify all of your changes to the module have been checked in, one should do a cvs release. This will verify that all of your local directory changes have been checked into the main repository. From the root level of the module type:

$ cvs release

This will prompt you to commit any changes from the module that were not previously committed and make it safe to delete the module from your local drive at that time.

Committing Your Changes to the CVS Repository

n The versioning schema resembles a directory path in Unix always starting from main.

n Branches are designated with a "/" then followed by the branch name and version number.

For example:
linux-p2p-wifi1.5/Gui2.3/GuiButtonA.1.2

n With branch Gui representing a branch from the mainline at release 1 version 5. Gui is at release 2 version 3. GuiButtonA is then a branch from gui at release2 version 3 and is up to release 1 version 2. This will lead to long tags, but this makes it possible to trace back to previous branches and where we branched and then merged. Merging is labeled by “//branch//” as follows:

n /linux-p2p-wifi.2.6/Gui.2.2//GuiButtonA.1.2//Gui.2.3/

n This represents GuiButtonA.1.2 branch merging back into the Gui branch after version 2.2 to help form version 2.3. Merging the Gui branch back into the mainline occurs as follows:

n /linux-p2p-wifi.2.6//Gui.2.3///linux-p2p-wifi.2.7

n Now the Gui branch is merged back into the mainline of the code. The user may then search on the Gui branch to obtain branch history such as when the branch formed and any branches from the branch. Maintaining the branch merging in the version name allows us to easily track and identify likely problem spots. Branching will not cause errors yet integrating code during a merge introduces chance for error.

n This makes it possible to trace back to previous branches and where we branched.