The purpose of the UD6/CMtool driver is to store your Uniface source code in a format that can be version controlled. Procedures for doing this with PVCS Version Manager are described in the previous sections of this "How to:" guide.
However Uniface developers use more than just Uniface source code, a typical workflow involves modifying source code, compilation, test.
Therefore it is important how and where the compiled objects (eg:
.aps and global objects and compiled entity definitions) are stored and accessed by the IDF.
The way these are handled can vary considerably depending on several factors, including:
None of these should effect how you build a "release". A "release" should always be built from a ckeckout of a particular "baseline" into an area separate to your development environment, and therefore is not impacted by ongoing development work.
Regardless of how your workflow - the impact of modifying "shared" objects in Uniface must be carefully managed - and a workflow designed that suits your development practice. In particular changing an entity definition may need to be done in isolation from other teams since it effects the components, the model and any test data being shared amongst teams.
Ideally if a model change is being implemented it should either:
If each development team has their "work area" on a "network drive" then the "network drive server" can be configured to recompile all the compiled objects for each environment every evening. In this case changes can be easily made to the model after close of business but before the automatic compiles execute.
Since Uniface does not provide a way to compile an individual global variable or constant, it can be confusing if two teams have a requirement to add or change global variables or global constants and re-compile the library. Solutions for this are similar to other global objects which are discussed below.
The simplest scenario is where "all developers see all changes by the development team", compiled objects may be controlled or uncontrolled.
In this scenario there is no need to have a separate "Working" directory and INUSE file, the reference area can be used as both - when a file is "checked out" it will overwrite the "ready only" file.
When a developer compiles a form, the new FRM overwrites the old one and all developers can "see" the change. Similarly - all developers see and use the same set of compiled global objects in the UOBJ table.
It is much more difficult to design an optimal workflow with PVCS Version Manager and Uniface where separate teams exist and/or the compiled objects are controlled.
In this scenario each "team" must use a separate "work area", this is achieved by each team having an "INUSE" file (usually located on a "network drive" shared only by them) and an ASN file with the
USYS$UD6_PARAMS=listdir inuse-filename. The "INUSE" file is updated by the triggers in PVCS when a file is checked in or out.
This works because UD6 will usually look in the reference directory for the source code, unless overridden by the "INUSE" file. However this does not work for the compiled objects.
Uniface can also redirect where it "looks" for compiled objects - but this cannot be done in "real time" - only when Uniface is started.
There are three solutions:
uniface.exeto test their compiled objects with an ASN file which redirects the compiled objects
This is the least optimal solution. Even though you have several "work areas" so that teams can keep their work separate to each other - all teams share the same compiled code, which can lead to confusion in testing.
This solution works quite well as long as teams work quite independantly of each other - which according to some CM methodologies they should.
When a "project" is started the current compiled objects (including the database for the UOBJ table) are copied. The project team will use these objects exclusively.
However if another project team checks work in to PVCS then the compiled objects for this other team will not have been updated. This can be solved by running a
idf.exe /all on each teams work area each night. Since the global objects are compiled into the UOBJ table each night this also solves any difficulties with the global objects.
This technique comes the closest to simulating the same effect as UD6 provides with the source code. However it requires that the developers use a slightly different workflow during testing.
UD6 1.03 provides an updated
del2list.exe which can update the
[FILES] section of an
If the file being checked out is a compiled object (eg:
.frm) then rather than update the "INUSE" file, the
.asn file is updated which tells Uniface to look in a different place for the new FRM file. See the reference page for add2list.exe and del2list.exe for more information about the
There are two drawbacks to this approach:
.frmfile when it is started
Compiled messages, and other global objects can often be shared across all teams with little detrimental effect. A notable exception is where 2 differnet teams each need to add a global variable or constant, in which case the teams should share the source code for global objects as well as the compiled UOBJ table. Sharing the source accross projects can be done by choosing a different "Work Area" to check these "out" to.
In order to test a component that has been "checked out" during an IDF session the developer would normally test it using another Windows shortcut to the
idf.exe using the
/tst myform switch.
How to use the driver with PVCS Version Manager (cont.)
Taking control in PVCS Version Manager
Releasing a form using PVCS Version Manager
Checking a form in using PVCS Version Manager
Adding a form using PVCS Version Manager
Finding the differences in versions using PVCS Version Manager
Problems when using PVCS Version Manager
A methodology to Uniface source code control
|$Revision: 18.104.22.168 $ $Date: 2003/09/16 17:51:58 $||[zum Seitenanfang]|