Re: Wanted: info on Oracle code management
Date: Wed, 10 Mar 93 22:17:52 GMT
Message-ID: <1993Mar10.221752.9690_at_butch.lmsc.lockheed.com>
Upon suggestion, I am posting the replies I received on Oracle Source Code Management.
What we are looking for is a commercial tool (do not want to invest the time in building one ourselves) that can be used on a VAX/VMS platform as well as UNIX. RCS seems to be a popular choice and we are trying to get more information on it.
I appreciate the comments from those who sent them. If anyone has anymore information to share on RCS especially the compatability to VAX/VMS, I would be grateful.
-Christine Hill
Lockheed Missiles and Space
Message-Id: <9302241320.AA19706_at_comm.mot.com> Date: Wed, 24 Feb 93 08:15:15 EDT
From: garth_at_comm.mot.com (Garth Kennedy) To: hill_at_aspen.ops.lmsc.lockheed.com
Subject: Re: Wanted: info on Oracle Code Management
My systems are set up so that ALL source code is contained within SCCS
(RCS or equivalent wotld work as well). We have a set of utilities set up
so that developers can "checkin/checkout" or "browse" code from the sccs
owned source library. All production implementation is done by the systems
administrator who executes a make file which recreates the "executable"
(OK renames scripts) and copies the "executable" to the desired location.
We do not allow any non-text files in sccs, that is .frm files are not present, but the associated .inp files are present with a make file to manage the conversion.
This is in a System V release 3 environment, but I have reason to believe that the same base functionality exists on VAXen as well.
Hope this helps. If there are questions e-mail or phone as you desire.
+------------------------------------------------------------------+ | Garth Kennedy garth_at_comm.mot.com Voice (708) 576-3786 || Private Trunked Systems Div. Motorola Inc. FAX (708) 576-6028 |
+------------------------------------------------------------------+
**************************
Date: Wed, 24 Feb 1993 11:20:26 -0800
From: Rajasimha Aji <raja_at_well.sf.ca.us>
Message-Id: <199302241920.AA15709_at_well.sf.ca.us>
To: hill_at_aspen.ops.lmsc.lockheed.com
Subject: Re: Wanted: info on Oracle Code Management
I have set up a development environment using CMS and MMS to control Oracle source code (i.e., .inp, .rex and so on). I have also created MMS macros which generate executables (.frm, .rep) etc. This environment is not currently being used by anyone now so I am not sure as how well it works.
The MMS macros are somewhat messy - especially the parts that generate menus and use referenced forms.
I have heard that Forms 4 and SRW 2 use a binary format in .inp and .rex files. While CMS can handle binary files, the space savings you get from storing multiple versions of source files are lost.
Date: Thu, 25 Feb 1993 18:35:45 +0800
From: Marcus Hayes <mah_at_dialix.oz.au>
Message-Id: <199302251035.AA05311_at_perth.dialix.oz.au>
To: hill_at_aspen.ops.lmsc.lockheed.com
Subject: Re: Wanted: info on Oracle Code Management
We are a major unix and dos site ... all our applications are in Oracle. The following is a hilite of what weve done ....
- We developed application standards, unix standards ... We built a set of utilities that enforced these standards, create default standard forms.
- Each system has a dev, test, train and prod areas. The dev area is dropped when the project is fully settled.
- All our source code is monitored by RCS shell scripts. We have utilities that dump each oracle products item into an ascii readable form.
forms 2.3 - 3.0 - inp file
report - rpt and rex file
4. Documented common library routines for forms development. These are also
stored within the RCS system.
Initially we played with SCCS but RCS was much simpler and quicker for our purposes.
All our datamodels (27 projects so far) are kept within an internally developed case tool (a set of simple screens... that enforce naming conventions ... and generate the sql code to create database objects), yes, we have bought oracle case - but we wanted a system that all our project leaders could access at the same time - and we can customise it to our needs.
I've been a bit vague if you want to discuss any of the above in more detail feel free to drop us a line.. (please excuse the typos)
+=======================================================================+
| Mark Hayes |
| ,-_|\ Corporate Systems Internet: mah_at_DIALix.oz.au |
| / \ 83 Mill Point Road Phone: +61 9 264 1616 |
| *_,-._/ South Perth WA 6151 Fax: +61 9 474 2553 |
| v |
+=======================================================================+
Theres a mountain of code to my next ski trip ....
******************************
Date: Thu, 25 Feb 93 12:44:09 -0700
From: mdb423_at_oregon.et.byu.edu (Matthew D. Bennett)
Message-Id: <9302251944.AA02996_at_oregon.et.byu.edu>
To: hill_at_aspen.ops.lmsc.lockheed.com ()
Subject: Re: Wanted: info on Oracle Code Management
If you have the money, a good case tool should help you out. Oracle even has one. Most developers that I know, build their own source code management system in Oracle though. Depending on the size of your developer group and the size of the project, this can be a good solution or you may want to look at something else.
Matthew D. Bennett
Date: Fri, 26 Feb 93 21:55:00 EST
From: dtb_at_otto.bf.rmit.oz.au (David Bath)
Message-Id: <9302261055.14291_at_otto.bf.rmit.oz.au>
To: hill_at_aspen.ops.lmsc.lockheed.com
Subject: Oracle code version control
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.
- 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
- SQL*Plus Scripts
RCS keywords are generally placed in REMark lines - 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. - 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. - 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:
- 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.
- DOS RCS executables are available from SIMTEL. Again, in Australia, try archie.au (somewhere under ~ftp/micros/pc/oak, I forget which subdirectory).
- 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.
- 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" - EpictetusReceived on Wed Mar 10 1993 - 23:17:52 CET