Re: Source Code Control for Stored Procedures, any suggestions???

From: PKelley772 <pkelley772_at_aol.com>
Date: 1996/01/13
Message-ID: <4d85h5$ha5_at_newsbf02.news.aol.com>#1/1


>From: "Bruce W. Robinson" <bruce_w_robinson_at_jf.intel.com>
 

>I would be interested in hearing anyone's experiences with source code
 version
>control mechanisms for Oracle stored procedures.
 

>Thank you,

Not much experience yet, but we're working on it. We use sccs (sequent), storing the sql scripts that are used to create the procedures. Programmers can use procedure builder or other gui tools to create their programs, but the source ends up in text files in sccs. We use shell scripts and a single pro*c program.

We have the following functions:

  1. Extract any program unit from the database into a standard format in a

     file with a standard file name (2 files for packages). Extraction is done

    by a) single program name b) wildcarded program name like %hire%     or c) ALL, which extracts all program units.

  2) extract all program units from the db and compare them with what's in sccs.

       This will be modified to allow individual or wildcarded comparisons.

       
       To be added :
 
         1) show me program names in the database not in sccs  
         2) sccs filenames whose program are not in the database
    
       We find that some white space from source (.sql) is not stored in
the database, in particular lines that contain only a carriage return. False diffs between extracted programs and programs typed by users will be raised unless you handle this.  

  3) get latest version of program units from sccs and apply them to the database

      Dependencies can be difficult to determine, which makes it difficult to

      figure out the order in which to apply the files. Multiple passes are needed

      when applying a large number of units to a new database.

Miscellaneous:

      Since branching is allegedly something to be avoided in sccs, we expect to have separate sccs libraries for new development and production.  

      We decided that the second line of each source file gets sccs keywords. For triggers, the version information then ends up in the trigger description field (user_triggers).

Paul Kelley     Received on Sat Jan 13 1996 - 00:00:00 CET

Original text of this message