Chapter 4. How to Recreate Old Versions

Table of Contents

1. aecp
2. Finding Delta Numbers
3. ${version}
4. Out Of Date

It is possible to recreate old versions of your project. This is done using the delta number assigned to every completed change.

1. aecp

Recreating the sources is usually done to recreate a bug. To this end, it is also usually done from within an existing change. The aecp(1) command is used to copy histprical file versions into a change.

The aecp(1) command has some options which are used to perform the source recreation:

-DELta number This option tells aecp(1) to extract an historical version of the files, rather than the head revision (the one visable in the baseline). You need to know the delta number of the change, assigned at integration time, not the change number.

-BRanch number If the historical version is on a different branch than the one the current change is on, use this option. The branch number is to the left of the "D" in version strings.

-DELta-From-Change number This option tells aecp(1) to extract an historical version of the files, rather than the head revision (the one visable in the baseline). You only need the change number to use this option.

-DELta-Date "string" This option tells aecp(1) to extract an historical version of the files, rather than the head revision (the one visable in the baseline). You only need the date the change was integrated to use this option. It understands many forms of written (English) dates, but try to avoid ambiguous month numbering (it can be confused by some European vs. American numeric formats, use month names instead).

2. Finding Delta Numbers

You can find delta numbers in a number of ways:

  • The “ael change-details” command will list change details. If changes are completed, their delta number will appear at the top of the listing.

  • The “ael project-history” command lists all integration for a project, including their change numbers and delta numbers.

  • The aeannotate(1) command lists the file source, annotationg each line with the developer, the date and the version. To the right of the "D" in the version is the delta number.

  • The #{version} substitution (see aesub(5) for more information) is covered in the next section.

In addition, you may need to use the -BRanch option, if the historical version is on a different branch than the one the current change is on. The branch number is to the left of the "D" in version strings.

3. ${version}

The build_­command field in the project config file may be given the ${version} substitution, which you may use to embed the version string into your executables. You could, for example, have this string printed when yoiur program is given the -version command line option. For example:

% aegis --version
aegis version 4.15.D012
%

Armed with this version string, you can recreate the sources for the version being executed. The command

% aecp --change=4.15.D012 .
%

would be issued from inside a suitable change. This form of the aecp -change option combines the -BRanch and -DELta options into a single command line option.

4. Out Of Date

Once you have recreated your sources and rebuilt your project, and presumably fixed the bug you were hunting, there are a couple more steps.

  • The first is to remove unchanged sources. Do this with the

    % aecpu -unchanged
    %
    

    command. This removes from your change all files which were not changed by this change. This cuts down on the clutter and makes the next step much easier.

  • The next step is to merge the files. Because you are working with historical versions of the files, Aegis will think they are out-of-date and want you to merge them. Do this is the usual way (using the aem(1) command). Remember that Aegis will stash a backup copy with a “,B” suffix before merging.

You may find the following command

% ael cf | grep '('
%

useful for finding out-of-date files.

  • Once Aegis thinks all the files are up-to-date you then need to rebuild and retest before completing development.