Re: Wanted: info on Oracle Code Management

hill_at_aspen.ops.lmsc.lockheed.com () writes:

>I am on a team that is developing Oracle Application Standards. My task
>is to research different methods for managing the source code of our
>applications which includes .frm, .sql, .rep, .dmm type files.
 

>If anyone out there has tackled such an issue and has advice to offer, I would
>appreciate it (email would be great). Specifically, we are looking at which
>products would be best to use like VAX CMS etc.
 

>Thanks,
>Christine Hill
>Lockheed Missiles and Space Co.

VERSION CONTROL FOR ORACLE APPLICATIONS SOURCE

0. Introduction

	The issue of version control for Oracle applications code is a
	sticky one and is complicated by issues of different operating
	systems, but most especially by Oracle's predilection for
	non-ascii storage formats.  Note the ruckus caused when Oracle
	proposed no ascii .inp format file for Forms4.

	Version control is an important issue for MIS departments however
	and MUST be successfully addressed, otherwise things start falling
	apart.

	This file has some formatting using a tabstop of 8, so if it looks
	weird, change your default tabstop for your editor.

1. Choice of Version Control Tool

   ---

   There are a number of version control tools available for different platforms. These include CMS for VAX/VMS and SCCS for AT&T UNIX. In the MS-DOS world, most formats are proprietary.

	Our choice of tool was RCS however, because of the following
	reasons

	1.  Reports and management are more user friendly than SCCS, the
	default tool for UNIX, our main development platform (although
	our network includes DOS and VMS nodes).

	2.  Source code is available in the public domain from most
	sites archiving GNU code.  This makes it possible to port it
	fairly easily, especially if you are running VAX/VMS and have
	either the POSIX C libraries or using GNU C.  DOS source code
	and binaries are also available.  We can also modify the way
	some of the programs (particularly the report programs) work to
	perform extra things we like.

	3.  The binary files used to store initial code and deltas (from
	which any version can be retrieved) are compatible across
	architectures.  For example, I can use the DOS RCS programs to
	extract source files from the binary RCS files transferred from
	the UNIX machine.

	4.  An add-on, CVS, also available in the public domain, permits
	fairly easy management where TWO sites are carrying out
	concurrent development.  This is common where a vendor is
	providing the source, but some local changes are being made.

2. Outline of RCS operation

	Essentially, you check in a file to RCS (with optional security
	information, "aliases" for the version and state information).
	Subsequent check ins are stored as deltas within the RCS storage
	file, (unless you are checking in binary files, in which case
	the entire new copy is stored).

	For ascii files, RCS looks for certain keywords, and on check
	out, substitutes the version specific information.  These
	keywords include
		$Author$	The user name of the file owner
		$Source$	Full path/filename of source
		$Filename$	filename without path
		$Date$		Date and time of check in
		$State$		A keyword you can assign
				e.g. "Cut", "Tested", etc
		$Id$		A combination of all information

	You can also cause RCS to include in your source all comments
	made specific to that version, for example, the reason why
	changes had to be made.

3. Basic Philosophy of Version Control with Oracle Applications Source

	Wherever possible, use version control on ASCII representations
	of the code.

	Thus for forms, use the .inp file, for menus, the .sql file
	produced by "exporting" the menu.  For SQL*Reports, .rex files
	rather than .rep files are put under version control.

	The keywords are placed in the source, however you like, the
	ASCII file produced, checked in to RCS.  When moving to a
	testing or production environment, the source is checked out of
	RCS (resulting in keyword substitution) and "compiled" in the
	target environment to produce the runtime application.

4. General Caveat

	Where source code for an Oracle application can be stored in the
	database (such as forms or menu), keyword expansion of the $Id$
	keyword can be dangerous, as it may expand to MORE than the
	database allows to be stored.  Thus, rather than use $Id$, I use
	the more atomic keywords on different lines, these being
	unlikely to expand above legal limits.

5. Specifics for some products

1. SQL*Plus Scripts

   ---

   RCS keywords are generally placed in REMark lines
2. SQL*Forms

   ---

   RCS keywords are placed in the comments at forms level. Selected keywords are placed as default values for non-enterable fields, so that the user can see version information.
3. SQL*Menu

   ---

   RCS keywords are placed either in the titles section of a menu or in the default value for a parameter, depending on how we want to use the keyword. If you do not want to do this, put a wraparound function to create the REMark line(s) at the top of the .sql file prior to checking it in. This will NOT affect compilation of the resulting .dmm.
4. SQL*ReportWriter

   ---

   Major BUMMER, .rex files are not "sensible" ASCII that will permit expansion of RCS keywords. The only way I know how to solve this is to version an ascii file produced by selecting the data out of the report writer internal tables and versioning that, then using SQL*Loader to put them back into the SQL*ReportWriter tables in the production environment. While this would work, I have not tried it myself (as we do not use RW), but apparently some group in the US has a tool that performs this task. If anyone knows how I can contact that group, let me know please.

Notes:

1. RCS and CVS, together with the GNU compiler you may need are available from most GNU archive sites. If you are in Australia, try archie.au in ~ftp/gnu. Less up-to-date versions are also available in comp.sources.unix.
2. DOS RCS executables are available from SIMTEL. Again, in Australia, try archie.au (somewhere under ~ftp/micros/pc/oak, I forget which subdirectory).
3. I think I have seen OS/2 versions of RCS floating around. You could probably get the DOS patches and compile it for the OS/2 environment with a few mods anyway.
4. My company is more than willing to assist (for payment) with further consultation, porting and implementation of RCS and associated management, providing you are in Australia. Contact Wayne Bellman or Gerry Carcour via phone or the addresses provided.

---
David T. Bath             | Email:dtb_at_otto.bf.rmit.oz.au (131.170.40.10)
Senior Tech Consultant    | Phone: +61 3 347-7511 TZ=AEST-10AEDST-11
Global Technology Group   | 179 Grattan St, Carlton, Vic, 3153, AUSTRALIA
"The robber of your free will does not exist" - Epictetus
-- 
David T. Bath             | Email:dtb_at_otto.bf.rmit.oz.au (131.170.40.10)
Senior Tech Consultant    | Phone: +61 3 347-7511 TZ=AEST-10AEDST-11
Global Technology Group   | 179 Grattan St, Carlton, Vic, 3153, AUSTRALIA
"The robber of your free will does not exist" - Epictetus