|
|
Version 0.4
Edition 1
|
Document ID:
|
CVSI
|
|
Author:
|
John Newbigin
|
|
Reviewed by:
|
Jaycee Phua
|
|
Date:
|
Thursday 29 April 1999
|
Revision History
|
Date
|
Modifications
|
Reason
|
Version
|
|
1999.03.03
|
Document created
|
CVS Instructions
|
0.1d
|
|
1999.04.29
|
Document contents formatted (JP)
|
Conformance to Style Specification
|
0.2d
|
|
1999.09.02
|
Document formatting updated (JP)
|
Reflect
changes in Style
|
0.3
|
|
1999.11.30
|
Anonymous access added
|
Need to allow the Open Source Community access to source
|
0.4
|
Table Of Contents
1. CVS Access from a Unix-Based System
2. CVS Access from a Windows-Based System
3. Anonymous CVS Access
4. Building the source
1. CVS Access from a Unix-Based System
The CVSROOT is located in the directory "
/teamproj/cvsroot/teamb
"
All Team Synergy members have access to this Repository.
Before you access the repository, you have to set your CVSROOT
environment variable. On europa this is best done by editing the
.login file. The following command will
append the appropriate setting to the file:
|
%
|
echo "setenv CVSROOT /teamproj/cvsroot/teamb" >> .login
|
Otherwise you can edit the .login file using the UNIX Text Editor "vi".
Once this Environment variable is set up, you can access the Repository using
the cvs command.
It is highly recommend that you create a working directory for any checked out
files you have. You should change to this directory before checking out any
modules.
You can checkout (co) a module by typing:
This will create a directory called "test1" and download all the files to that
directory.
You can then edit the files in this directory as you please.
When it compiles (make must succeed), and it has been peer
reviewed (there will be a document on this) you can check it into the
repository. To do this, change to the "test1" directory and type
This will open vi and prompt you for your changes. You should describe the
changes you made and save and exit.
The files will then be uploaded to the repository.
If there are conflicts, you will have to resolve them. (More info to come)
There is no requirement to check in any files. If you decide that you don't
like what you have done, you can just delete the directory and start again.
Note that you can only check in files which belong to the repository. These
files must be explicitly added. This must be done after a peer review. The
command to add a file is:
or
Before the changes are made permanent, you have to commit them with the
following command:
Sometimes cvs will issue a warning and give an instruction such as
"run teama commit". This is a bug in cvs and it means "run
cvs commit".
This highlights an important point, CVS is for text
files only. And binary files will become corrupted unless
explicitly added with the "-kb" option. There are only a few types
magically recognised and made binary, but it is best to specify. Don't
delete any local files until you know they can be successfully checked out.
You can also delete file with the delete command
The file is not deleted, but moved to the attic in case
you ever need it back. Again, only do this after a peer review.
After you add a new file or delete a file, you must run a
script on europa to set the file permissions to allow everybody
the proper access to the files. The script is at europa in
the directory:
/teamproj/hit3058b/teamb/fixcvs
Other commands you will want to know are update and release.
If you have a checked out version of a module which you
have changed and someone else checks in a new version of a file, you
can get the new version to your directory with the update command.
or
which will apply to files in the current directory and all sub-directories.
Release will release a module and optionally delete it.
It will tell you about any changes you have made and is a good check before
deleting files. Change to the parent directory before executing.
There are more details at http://uranus.it.swin.edu.au/~jn/cvs/cvs.html#SEC151
I recommend everybody look at this document. I know it is
quite large but there is a lot of information in there. The best way to learn
however is to do it. I expect that everyone will check out the test1 module,
change at lease one file and check it back in. If you work in pairs, you can try
and resolve conflicts too. All developers should be competent at resolving
conflicts.
Other notes:
- Only the Configuration Management person (John) should
check out the CVSROOT module.
- Do not, under and circumstances change files in the
CVS directory.
2. CVS Access from a Windows-Based System
CVS access is available from the labs. The procedure is similar to using
it directly on europa, but there are a few issues to
take care of.
To set the CVSROOT, there is a script at
h:\hit3058\teamb\cvs\setcvs.bat
This will look at your user name and set the CVSROOT appropriately. The
easy way to do this is:
- Start a command shell
- drag the file setcvs.bat to the command shell
- give the focus back to the command shell and press enter
- type set and make sure that it is set up right.
Once this is done, you can log in to the cvs server using:
This will prompt you for your password. Enter your europa password.
You can then checkout files as described in the original document.
|
Caution:
|
When you type cvs login, your password is saved in what is
essentially plain text in the file
$HOME/.cvspass
. This maps to
c:\temp\.cvspass
which is accessible to anybody who logs in to
the machine. This is a huge security risk as the next person has
access to the repository from that machine can get your password for
europa.
|
You must either type
cvs logout
or manually delete the .cvspass file (ie.
not just send the file to the Recycling Bin) before
you log out of Windows NT.
Every file which is checked in to CVS should contain a line:
// $Header$
or
# $Header$
or
<!-- $Header$ -->
etc.
When CVS sees this, it expands it to contain version info and last
update info.
There are others you may want. Look at the specification located at:
http://uranus.it.swin.edu.au/~jn/cvs/cvs.html#IDX350
3. Anonymous CVS Access
For anonymous access to the repository you need to replace a few of the references in the above
sections, depending on what platform you are using.
First of all, the CVSROOT needs to be specified as follows:
1. Windows
set CVSROOT=:pserver:cohesion@cohesion.it.swin.edu.au:/home/teamb/cvs
The password for the anonymous account is "cohesion".
Anonymous access to the repository only allows readonly access, you cannot
update the repository directly and so any submissions should go through
the maintainers of this site.
4. Building The Source
Due to the inherent differences between Unix and NT, there is no simple solution to a
common build script. The current system of batch files does not work under Unix at all,
and requires a lot of manual configuration.
The new system was based around a cross-platform tool called make. Unfortunately, the make
currently in the labs is not compatible with the make on europa. To get around this, gnu make
for NT has to be stored on the H drive.
The solution was designed to provide a high level of utility, with a common interface on both platforms.
Another problem was the dependency checking for modified java code. There is still not a
perfect solution to this, but an interim solution is the glue file. Javac does dependency checking
when you compile code, but because our modular design has several ‘root’ files, the glue file acts
as a virtual root for all the code.
When you create a new plugin, you have to add it to the au.edu.swin.synergy.glue file to make sure
that it is compiled. You need to add an import, and instanciate it inside main.
Rather than explain the guts of the make files, here is a sample session that you might perform.
C:\> set CVSROOT=:pserver:cohesion@cohesion.it.swin.edu.au:/home/teamb/cvs
C:\> cd \temp
C:\> cvs login
C:\> CVS password: cohesion (password for anonymous access)
C:\temp\> cvs co workspace (check out the required directory structure)
C:\temp\> cd workspace
C:\temp\workspace\> co (check out the required files in the appropriate directories)
C:\temp\workspace\> cd src\bkasrc
edit the code......
C:\temp\workspace\src\bkasrc> make clean (delete compiled classes)
C:\temp\workspace\src\bkasrc> make (default build)
C:\temp\workspace\src\bkasrc> make client (run the client)
As you can see, the only work left to do is write the code.
There are a number of make targets for the bkasrc module. These include
| target | description |
| all | Build Bka & Plugins |
| jikes | Build Bka & Plugins using the jikes compiler (assuming in path) |
| glue | Build Bka & Plugins |
| debug | Build Bka & Plugins with debug enabled |
| deprecated | Build Bka & Plugins with deprecation enabled |
| client | Run client |
| server | Run server |
| debugclient | Run client in debugger |
| debugserver | Run server in debugger |
| clean | Delete all class files |
| jar | Create a jar archive |
| publish | (Europa only) create downloadable package |
It should be noted that most of these arguments can be combined to perform a number of operations
at once. For example, to make a clean build and run the client you would type:
C:\temp\workspace\src\bkasrc> make clean jikes client (delete classes, compile with jikes and then run the client)
You can download the required GNU Make for Win32 file and Jikes compiler from this site.
These files should be extracted into your build directory. If you're running this on Linux or another
Unix, the required version of make should already be on your machine. If you get errors indicating that make
can't find the java compiler under c:\apps\jdk1.2.x... you may need to edit the make file to reflect
the appropriate directory.
Note: The root file is the file which when compiled, will trigger dependency checks which cover the entire source tree (it depends on every file).
|
