|
|
Using CVS at the ING |
The naming convention is of the form ING_README.module-name.lsm where the module-name is that of the current module.
The file format is that of the Linux Software Map Entry Template (Release: 09AUG94) as this contains most of the information needed. an example is shown:-
Begin3
Title: The name of the package. Please use the same title for
the LSM entry of each version, so as to make it easier
to find entries for new versions of packages that
already have one in the data base.
Version: Version number or other designation. Use a date if
nothing else is appropriate.
Entered-date: Date in format ddMMMyy of when the LSM entry was last
modified, where dd is 2-digit day of month, MMM is
ALL-CAPITALIZED first 3 English month letters, and yy
is last two digits of the year in the Gregorian
calendar. Note that you should fill in both Version
and Entered-date.
Description: Short description of the package.
Keywords: A short list of carefully selected keywords that
describe the package.
Author: Original author(s) of package. In RFC822 format (i.e.,
something that will fit into a From: or To: header of a
normal Internet mail message). Preferred format:
mailname@site.domain.top (Full name)
Other formats will be converted to this format, if time
and energy of LSM maintainer will allow it.
Multiple persons may be given, one per line.
Maintained-by: Maintainer(s) of ING port. Same format as Author.
Primary-site: A specification of on which site, in which directory,
and which files are part of the package. First line
gives site and base directory, the rest give the sizes
and names of all files. Names are either relative to
the base directory, or full pathnames. If the ftp
site does not use Unix style pathname syntax, then
the full pathname must be given every time. The pathname
must not contain spaces. Example:
Primary-site: sunsite.unc.edu /pub/Linux/docs
10kB lsm-1994.01.01.tar.gz
997 lsm-template
22 M /pub/Linux/util/lsm-util.tar.gz
The file size may be given in bytes (no suffix), kilobytes
(k, kb), or megabytes (M, MB). The suffix may be separated
with spaces, and may be in upper case or lower case. The
size can be left off.
For very large packages that are contained within
one directory (say, a distribution), only the directory
need be listed. Adding a trailing slash makes it clear
that it is a directory.
The filename should be the final location, not an
"incoming" directory. If you don't know the final
location, at least make a good guess (since files _will_
be moved from incoming, it is not a good guess).
Alternate-site: One alternate site may be given. It should not be a
site that mirrors the primary site (these are best
found from a list of mirror sites), but should be one
that maintained separately. More sites carrying the
package can be found using Archie. The syntax is>
the same as for Primary-site, but if there is only one
line (i.e., no files are specified), they are assumed
to be the same as for Primary-site.
Alternate-site: ftp.funet.fi /pub/OS/Linux/doc/lsm
Alternate-site: foo.bar /pub/lsm
11 kB lsm-1994-01-01.cpio.Z
0.1 kB lsm-template.Z
22 MB lsm-util.tar.gz
Original-site: The original package, if this is a port to Linux. Syntax
is as in Primary-site, with the same handling of missing
filenames as in Alternate-site.
Platforms: Software or hardware that is required, if unusual. A
C compiler or floppy disk would not be unusual, but a
Python interpreter or tape drive probably would be. If
the requirements are evident from the description, it
need not be repeated here.
Copying-policy: Copying policy. Use "GPL" for GNU Public License,
"BSD" for the Berkeley style of copyright, "Shareware"
for shareware, and some other description for other
styles of copyrights. If the use or copying requires
payment, it must be indicated.
End
A copy of the file will be sent to CFG when the program is installed into the CSG executable directory.
All 3rd Party Software will be imported into the "external" directory in the CVS repository.
Two other directories have been created for the Instruments Group (instproj) and the Detectors Group (ccdproj). With the intention of the use of CVS for their software repository.
From the projects root directory, the following module directory's should be available:-
/<module>/
|
|--bin/
|
|--src/
|
|--lib/
|
|--etc/
|
|--man/
| |
| |--man1/
|
|--include/
|
|--test/
|
|--doc/
| |
| |--html/
|
|
|--Makefile
(or Imakefile)
The bin directory will contain the executable program for testing, it is included as a placeholder and will normally be an empty directory in the CVS repository (Mandatory).
The src directory will contain the source files. these will be C, Fortran, shell or tcl programs as required (Mandatory).
A lib directory is only required if special libraries are required (Desirable), or the source code produces a library for Installation (Mandatory).
An etc directory is intended to contain files relating to the executable configuration of the program (Desirable).
The man directory will contain the man pages for the application. (Mandatory).
The include directory is required for the included header files (Desirable).
The test directory will contain files used for testing the program or library (Mandatory).
The doc directory will contain other documentation as required, for example a html directory is shown for any web pages that may be written (Desirable).
The Makefile (or Imakefile) is required for compilation of the sources and installation of binary executable files or shell scripts (Mandatory).
/<module>/
|
|--submodule1/
|
|--submodule2/
|
|--doc/
| |
| |--html/
| |
| |--word/
| |
| |--tex/
| |
| |--pdf/
|
|
|--Makefile
(or Imakefile)
The Makefile (or Imakefile) is again Mandatory for Release of the sub modules.
The doc directory only requires a suitable sub directory if the documentation exists.
As an example for the C language the following is suggested for the C source file and C header file.
In the C source file the construct 'const char id_header_c[] = "@(#)$Id:$";' is intended to embed the information into the binary executable file for system debugging. See the manual page for ident(1) for further information (Mandatory).
In the C header file the construct '#pragma ident "@(#)$Id:$"' is also intended to embed the information into the binary executable file for system debugging (Mandatory).
Source code files for other languages will also contain suitable constructions to facilitate system debugging and user information (Mandatory).
Checkout the unixstarterkit module from CVS for a complete module
example.
The command :- cvs checkout unixstarterkit
will give it to you.
Check with the CVS manager to define a suitable module name for your project.
Ensure that the file permissions on the directory you are in and subdirectories and files are drwxrwxr-x failure to do this will not allow members of your group to checkout your source code.
All files that are created during compilation should be removed from the directories. For example all object file, and the compiled executable program. If you use Imake and have an Imakefile then the Makefile should be removed. Any files created when the executable program is run should be removed. The intention is to create a module in CVS which contains only the most necessary files.
Use the File->Import command in the Module Browser window as this will also update the CVSROOT module file to generate the information displayed on the Module Browser window. The Module Browser window is started from the main TkCVS window under the File->Browse Modules selection
You may check that this is correctly imported by using the module browser window.
Note that clicking on the + sign in the window will expand the directory listing to show all the modules. Your new imported module should be in this list.
When tagging files in CVS the tag word RELEASE has been reserved. Use tag words appropriate to your use ie TEST-1-1 or VERSION_2-0-b.
It is not necessary to delete incorrectly tagged sources, merely update your version or test tag number.
The intention when checking in source code is to ensure that if the source code requires compilation or assembly that this has been achieved without fatal error. So please ensure that your C program/Fortran program etc. will compile before check-in.
It is not necessary to tag the code every time, but when a complete set of sources produce a working program suitable for testing.
This can be checked by using the groups command.
Source code may be shared by all users at ING by importing the source files as a member of the ingcvs group, see the chgrp(1) command.