Procedures for handling compiled objects with Version Manager

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: .frm, .rpt, .svc, .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:

• Developers work individually or in teams
• All developers see all changes by the development team
• There is more than one development stream (eg: maintenance and next release)
• Compiled objects are stored directly or via polyserver
• Compiled objects are stored on a local drive or a network driver
• Compiled objects are controlled (stored in PVCS Version Manager) or not controlled

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.

Altering shared objects like entity definitions and registers

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:

• Be immediately propagated to all development environments
• Be done in complete isolation (a development environment where no source code, compiled objects or test data is used by any other team

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.

Simple Example

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.

Difficult Example

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:

• All developers share the same set of compiled objects (.frm, .aps etc)
• Each team has a complete set of compiled code on their shared network drive
• Each team use a separate idf.exe or uniface.exe to test their compiled objects with an ASN file which redirects the compiled objects

All developers share the same set of 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.

Each team has a complete set of compiled code on their shared network drive.

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.

Each team use a separate idf.exe or uniface.exe ASN file.

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 add2list.exe and del2list.exe which can update the [FILES] section of an .asn file.

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 -a switch.

There are two drawbacks to this approach:

• Uniface will only regognise the "new" location for the .frm file when it is started
• This does not provide a way to redirect the location of messages, global procs, global registers etc

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.