If you are using an external version control software such as Subversion (SVN) or CVS for versioning on an Open Systems platform you may want to use it also to version your Natural sources. You can already do so using the Local Versioning plug-in of Natural Studio (Natural for Windows) or the versioning functions of Natural for Eclipse or NaturalONE. However, in addtion to the external version control software PAC offers the support of the complete product lifycycle of an application from development to production environments.
Natural sources versioned with external version control software can be introduced into PAC without the need to create new versions of the sources in PACs ACF. Instead, a relationship to the versioned source text is kept.
The access to a source text in an external version control software is
realized by means of a REQUEST DOCUMENT statement
using the URL of the source code file. For details on the REQUEST
DOCUMENT statement please refer to the corresponding section in
the Natural Statements documentation.
The link of a PAC application to the status type External defines a foreign source from where Natural sources can be transferred into a PAC controlled environment and holds the information about the path into the external version control software. Additionally, a user ID and a password may be defined to such an application-status link. User ID and password are used when accessing the source in the external version control software.
It is possible to change the versioning location of existing applications from PAC versioning to external versioning and vice versa.
Usually, applications versioned in an external version control software do not have a link to a maintenance status, because bug fixing will be done in a development environment and the changed sources are committed to the external version control software and then newly transferred into PAC.
When new or changed Natural sources are transferred into a PAC
controlled environment, a transfer event from External to Control status (or
any other target status) must be created. This can be done by specifying the
fully qualified URL. When the transfer event is executed, the handling is the
same as with other migrations from a development status into a PAC controlled
environment. PAC gets the source by means of a REQUEST
DOCUMENT statement and writes it into the
PCF, compiles the
sources in the PCF and creates a new version of the cataloged object in the
ACF. DDMs are written
into the PCF. But instead of the source text the used URL is stored in the
ACF.
Before storing the source into the PCF, the line numbers and line number references will be recreated.
The Natural member name, the programming mode, the save date, the user and the code page information will be extracted from the source text. This information is either inserted into the source text by the Local Versioning plug-in or by Natural for Eclipse. If that information does not exist, default values will be used. The member type of the source file can only be derived from its extension. Those URLs that do not allow to determine the member type will be rejected.
From this point on the already existing deployment mechanism of PAC can be used. If the source is accessed again, the stored URL has to be used. The function Display Object Version displays the URL of an object. If there is a need to maintain a program (e. g. for bug fixing), the URL of the object that is to be changed in PAC has to be picked. Then the library contents of the branch used when transferring the objects must be checked out.
After the changes are made and commited to the external version control software, a new branch must be created. An example of how to proceed with Subversion as an external version control software is described in the Local Versioning section of the Natural Studio Extensions documentation.
When using e. g. SVN as an external version control software, the
command svn diff <new-branch> <old-branch>
--summarize produces a list of URLs of those sources that were
modified and added. This information can also be written to a text file. If
workfile 7 is defined as the Entire Connection workfile such a text file can be
used as input for the IMPORT command in the Migration List
editor.
Caution:
Please note that the above mentioned command produces only URLs
that denote the head revision (the latest revision) of a source. However, since
the URLs are required for future access, you are strongly recommended to use
unique URLs (e. g. containing information about a specific revision, branch or
both). Developers must create a branch in the external version control software
before transferring the objects into PAC to make sure that no changes are
committed into this new branch. The existing branch must be freezed for
editing.
Alternatively, the commands ADD EVENT and GENLIST EVENT allow to import lists of URLs (denoting the objects to be transferred into PAC) either instream (option I of GENTYPE) or by means of a workfile (option R of GENTYPE) in batch. The local GENLIST command accepts a base URL or the input from an Entire Connection workfile.
Another alternative is to use the SEL command in the object list editor to produce the object list from a base URL.
For Migration Paths having an External status as origin, no expansion is possible, because
there are no Xref data available in this status and
the contents of a directory can not be determined automatically.
Natural error messages are versioned externally as complete error message files (one per language). Whenever the URL of such an error message file is specified in the migration list then a new version in PAC is created for each message contained in the file. It is not possible to specify a single error message in the migration list of an event from status External.
The source of DDMs and Error messages is stored additionally in the ACF and thus handled as in previous PAC versions once under PAC control. This is done for performance reasons.