QA Build is often used for large systems developed by multiple programmers. In theory, such systems could be developed by programmers accessing one database through a network. In practice, development may be spread over several remote sites. In this situation, QABUTIL is the only practical means of interchanging updates. Without version control, this provides only a partial solution because it is not possible to:
Using the Version Control functionality built into QABUTIL you can eliminate these problems. This functionality is all contained in the Options Dialog on the Transfer menu.
The Options Dialog contains two sets of options - one relevant when exporting files, and one when importing.
On export, as well as full export files, you can now create partial ones containing:
On import, you can use the new version-control feature to provide warnings where one programmer's modifications overlap with another's.
The export options within the Options screen are:
| Export mode |
This takes one of three values:
|
| Changes from era | If you chose 'Changes from era' as the export mode, enter the name of the era. The era must exist on the database |
| Target database | If you chose 'Differences from target' as the export mode, enter the name of the database containing the old version of the database. The database must be accessible on your system |
| Export maps | Enable this option if you want maps included in the export file |
| Compact export |
Enable this option to use a compact export format. You may want to clear this option if you want to be able to examine or edit the export file, as the export may be marginally more human readable. |
| Export macros | Enable this option if you want macros included in the export file |
Your preferences are applied when you next create an export file by selecting an extract option in the QABUTIL Transfer menu. They are not preserved when you leave QABUTIL.
QABUTIL groups records from the QAB dictionary together. All the records in a group are examined when making exporting modifications.
For 'Changes from era' exports, if any record has a timestamp more recent than that of the era used all the records in group are exported
For 'Differences from target' exports, if any record is different from the corresponding record on the target database all the records in the group are exported.
QABUTIL groups records as follows:
Any deletion of one item from a group of related records will mark the 'header' record for the group. This ensures that the group is included in export files, even if no other updates are made to the group. Otherwise, a 'Changes from era' export would omit parts of programs that had only changed because of deletion.
On export, each record from a group of records is exported with a flag that indicates the status of the record. (This flag is an integer held in the cf= field with: cf=0 for unchanged records, cf=1 for amendments, cf=2 for insertions.)
The name of the era used to supply this information is included in the export file.
The post options within the Options screen are:
| List file | Enable this option if you want to include a listing of the
files being posted in the error output. This is recommended when
doing a version-controlled post because it makes it easier to track
down errors. Disable this option to speed up posting |
| Version control post | If several programmers are developing QA Build programs on multiple copies of the database, a potential problem can arise when using QABUTIL to exchange updates in that two programmers may have updated the same item. Enabling version control will minimize this problem. If you do, QABUTIL will warn you when any information contained in the export file would update records which have changed since a specified version (beginning of a specified era) |
| Era to check | For version control only, the name of the era to be used. A warning will be issued if information contained in an export file attempts to update a record modified since the beginning of the specified era. The era must exist on the database |
| Ignore update clashes |
Applies only to version controlles posts. If warnings are issued, posting is normally cancelled for the problem area, and related records. Enable this option if you want posting to continue regardless. This may be useful for testing a program, but may not have the desired effect, so we strongly recommend that you have a backup before posting with this option enabled |
| Test only posting | If enabled posting files perform testonly posting, which prevents the database from being updated |
Your preferences are applied when you next post an export file by selecting the Post option in the QABUTIL Transfer menu. They are not preserved when you leave QABUTIL.
During posting, QABUTIL checks the records to be updated to see whether their timestamps are earlier than the version-control era. A warning is issued if they are not, which will prevent posting unless you chose to ignore update clashes.
QABUTIL also does a comparison check to see whether the update would change the value of the records being updated. No update is performed for those records with unchanged values.
Related records are grouped together in the same way as during the export. If one record fails a check, its related records fail as well. So, for example, posting a procedure body causes a warning if any part of the procedure body being updated has a more recent timestamp than the version-control era.
If an era name is present in the file being posted and predates the versioncontrol era, the entire file is automatically rejected. To post the file you would have to choose to use the era specified in the file for version control. We have deliberately not automated this; the file is probably out of date.
Checking is also performed for deletions as follows: when a QA Build file is posted, records not marked as insertions (cf=2) must already be present or an error is flagged.
Updated records on the target database that are missing from the file being posted cause an error. For example, if you add a procedure to a QA Build program in "era-1" and post modifications to the same QA Build program using "era-1" for version control an error is produced if the procedure is missing from the export file.
Once an error is detected a report is produced comparing the data in the .QAB file with the data on the database. The format of this file is presently that for .QAB files but a more readable format may be adopted in future.
Using the facilities discussed, you can implement the following version control system for a multi-programmer development environment where each programmer works with a private copy of the database:
Initially, each programmer is given the same master database with the same era record on it, for example "era-1"
The programmers independently make changes to the database.
When a new master database is required each programmer produces a .QAB file containing his/her changes. Ideally, programmers should do this by comparing their databases with their own copy of the master, but they may also do it by exporting changes from "era-1".
The .QAB files are collected together and posted in turn to the master database, using the option to check records being updated have timestamps prior to the ERA (Version control post 'Yes'). The administrator may choose to perform a test-only posting of each file first and only really post the file if it goes through without errors, or even without warnings.
Problems are encountered where two programmers have independently updated the same records. The administrator can use the report produced by QABUTIL to decide how to resolve such problems. It may be decided that:
Finally, a new ERA record, for example "era-2", is added to the master database and a new copy of the master database is distributed to the programmers.
Limitations that need considering are:
It is not possible to detect the situation where a change made by one programmer requires changes to be made to other parts of a program, but the programmer does not make the changes.
This situation can only be catered for in one way - by dividing QA Build source code into two types:
Private code which can only be used by the owner of the code, and can be changed freely.
Public code which can be used by anyone, but can only be changed by agreement.
Because QAB does not support this notion some suitable naming convention must be adopted to make it clear into which category code falls.
The order of posting makes a difference. For instance, suppose one .QAB file is created with 'Changes from era' and contains 'marked' records, that is records that have been modified during the specified era but whose values are unchanged. This can happen, for example, where you delete a procedure and reinsert it. If this file is posted first and another file containing updates to the 'marked' records is posted no errors will be reported. If the order of posting is reversed errors will be reported. This is not particularly significant; it just means that the amount of effort in analysing clashes may depend on the order of posting. As a general rule of thumb, we recommend you post the largest .QAB files first of all so that if conflicts do emerge it will mean redoing smaller amounts of work.