| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re[2]: Free! RCS Training materials
Hi Amy,
Please send me a copy
Thanx
Dinesh
Here you go..
RCS CLASS INFORMATION
Teacher Information
Name : Amy Leone Phone : 790-5890 Company : ITS
Class Outline
Section 1: What problems does RCS solve?
Section 2: Who's responsible for RCS?
Section 3: How does RCS work?
Section 4: RCS commands
Section 1: What problems does RCS solve?
Some of you are using the PVCS version manager on DOS. RCS is the version manager for Unix. RCS:
Developed by Walter Tichy of Purdue University and available as freeware. Very flexible but requires a lot of scripts to be written if using for configuration building. Configuration building involves the ability to create all the executables for a system. Configuration control involves creating and maintaining different releases of software which may reside at different customer sites. There are some GUI tools which import RCS files and help to automate configuration building and control, including the PVCS configuration builder.
Section 2: Who's responsible for RCS?
Project Manager responsibilities:
The project manager is responsible for deciding what functionality belongs in each version of the software. He should determine this based on the customer's priorities. He should communicate to the programmers and build manager the name of each version and the functionality included therein.
Build Manager responsibilities:
It is the responsibility of the build manager to perform software builds, test them to insure that the required functionality is present, and send them out to the customer. The build manager should report any problems to the project manager. A common problem is that a programmer checks a file out of RCS, makes some changes, and forgets to check it back in. The build manager must make sure all files are checked in before attempting to build executables.
Programmer responsibilities:
Programmers are responsible for being aware of the functionality that belongs in each version of the software, the name of the version, and the date it is due. They should have their code tested and checked into RCS by the due date, and marked with a symbol that indicates the version number.
Section 3: How does RCS work?
RCS can store many different versions of the same program. It stores all these different versions in one file. The name of this file is your_program_name,v. It is referred to as a "comma v" file and is not meant to be accessed directly by the programmer. This file can only be manipulated by RCS commands.
The normal procedure for making changes to code that is stored in an RCS directory is to check it out with a lock, make your changes, test your changes, and check it back in. In order for a programmer to check files in and out of this central RCS directory, he must put a link to it in his working directory. The link should be named RCS. The command for creating a link is:
ln -s /usr02/apps/.../RCS RCS
If the programmer fails to do this, his programs will be checked in to his working directory instead of the RCS directory. The path name for the RCS directory is dictated by the system administrator.
The first time a module is checked into RCS, RCS will ask for a general description of what the module does. The programmer may type in as many lines of description as he needs. When a program is checked back into RCS after being altered, RCS will ask for a description of the change. These descriptions are stored in the comma v file.
RCS numbers different revisions of a program starting with 1.1, 1.2, 1.3, etc. A particular RCS revision can be assigned a symbol that corresponds with the version being sent to the customer. For example, revision 1.11 of a particular module in RCS may correspond to VERSION_4.1 which is being sent to the customer. As stated in the programmer responsibilities, the programmer must assign the appropriate symbol to the appropriate revision of his software module. In this case the symbol would be VERSION_4.1. In this way, RCS aids in configuration building.
It is possible to have branches. This may become necessary if the programs are to be maintained in a way that allows each site to have its own unique version. An example of this can be found in Windows. There are multiple versions of MS Windows, such as Windows 3.1, Windows 95, Windows NT, and Windows for Workgroups. All these versions have the same base software which has developed in different directions. Branches will have version numbers that branch off one of the main versions. A branch off of 1.2 would have version numbers 1.2.1, 1.2.2, etc.
The version of the software can be embedded in the source code and executable. This allows the user to determine which version of the software he is using. This is a way in which RCS aids in configuration control.
Section 4: RCS commands
Note: Before executing these commands, put a link to RCS in your working directory (see Section 3 for how to do this).
ci -u filename
Note: The first time you check a module into RCS, it will ask
you for a general description of what the module does. Type
in as many lines of description as you want. To indicate that
you are finished typing, hit enter and type a period and hit
enter again. When you check a program back into RCS, it will
ask you for a description of the change you made.
2. To check a program out of RCS with a lock:
co -l filename
Note that if you have a program checked out with a lock, no
one else can make changes to it until you check it back in.
3. To check a program out of RCS for read-only:
co -r filename
4. To review the text associated with the description and
changes, as well as to determine whether a file is currently
locked, use the command:
rlog filename
5. To compare revision 1.2 of filename with the version in your
current directory, use the command:
rcsdiff -r1.2 filename
To compare revision 1.1 with revision 1.2,
rcsdiff -r1.1 -r1.2 filename
6. To unlock a file that was locked with the co -l command:
rcs -u filename
7. To assign a symbol to a certain revision of a file, in this
case the symbol is VERSION_1 and the revision is 1.7:
rcs -NVERSION_1:1.7 RCS/filename
8. To check out the version of the file with the VERSION_1 symbol
for read-only:
co -rVERSION_1 filename
9. To de-assign a symbol from a file:
rcs -NVERSION_1 RCS/filename
10. To include information about your revision in your object and
executable for a C program, add this line to the declaration
section:
static char rcsid[] = "$Id$";
11. To include information about your revision in your object and
executable for a COBOL program, add this line to your working
storage section:
01 RCSID PIC X(200) VALUE "$Id$".
12. To examine information about which revisions were used to
create your executable:
ident your_executable
Received on Mon Jan 22 1996 - 11:38:22 CST
 |
 |