Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re[2]: Free! RCS Training materials

Re[2]: Free! RCS Training materials

From: AMY LEONE <AMY_LEONE_at_FMSO.NAVY.MIL>
Date: Mon, 22 Jan 1996 11:30:08 -0500
Message-Id: <9601221638.AA26326@alice.jcc.com>


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:

  1. Provides a central repository for source code.
  2. Allows only one user at a time to change a program.
  3. Saves all revisions of a program.
  4. Aids in configuration building and configuration control.

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).

  1. To check a program into RCS and leave a read-only copy in your working directory (recommended method):
                         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

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US