Introduction to FreezePointing |
17 |
 |
Changing Names
The current release of TeamWare uses new command names, so Table 17-1 summarizes the correspondences for you. Note that the old commands still work, however this manual uses the new commands and GUI names.
During the software development process it is often useful to create "freezepoints" of your work at key points. Those freezepoints serve as snapshots of a project that enable you to later recreate the state of the project at key development points.
This chapter refers primarily to the GUI. For information about the CLI, see the freezept(1) man page. The GUI is documented online. You can access the online help from any TeamWare GUI, by opening the pull-down menu from the Help button, and clicking on Help Contents.
Note - FreezePointing is a companion tool to the TeamWare product. Therefore, FreezePointing assumes that you are creating freezepoints of Configuring workspace hierarchies. You can also use FreezePointing to preserve nonworkspace directories that contain SCCS files. If you specify a directory that is not a workspace, a cautionary warning is issued.
At a later time you can use the freezepoint files to recreate the directory hierarchies contained in the workspaces.
Note - Nonworkspace directory hierarchies that contain SCCS history files can also be preserved using FreezePointing. FreezePointing issues a warning if the directory is not a workspace.
The freezepoint file that FreezePointing creates is a text file that lists the default deltas in SCCS history files in the hierarchy. When you later recreate the hierarchy, FreezePointing uses those entries as pointers back to the original history files and to the delta that was the default at the time the freezepoint file was created.
Note - The recreated hierarchy will not contain the original SCCS history files; only the g-files represented by the default deltas from the original hierarchy are recreated. The default delta is the delta that would be
When you create a freezepoint file, you specify directories and files to
You can later use FreezePointing to recreate the source hierarchy. You specify the name of the freezepoint file, the path name of the directory hierarchy from which the deltas are to be extracted (if different from the hierarchy from which it was derived), and the directory where you want the source hierarchy recreated.
Extract
The extract operation consists of creating a new directory hierarchy based on the information contained in the freezepoint file. The new hierarchy is comprised of g-files defined by the default deltas in the original SCCS history files; the history files themselves are not recreated. Deltas are extracted from SCCS history files located in the original source workspace. Source Workspace
The source workspace is the directory hierarchy that contains the SCCS history files from which the freezepoint file is created. Usually, the source workspace is also the directory hierarchy from which g-files are later extracted to recreate the hierarchy.
Note - You can specify an alternate source directory at the time you perform the extract operation.
Destination Directory
The destination directory is the top-level directory into which the files listed in the freezepoint file are extracted. You specify the path name of this directory in the Extract pane of the FreezePointing base window.
Starting FreezePointing
| To start the FreezePointing GUI, type the following: |
demo% twfreeze & demo% |
Note - You can also type the path name of a directory or file into the chooser Directory field and then click SELECT on the Add to List button.
Note - Show Default displays the default source workspace in the Workspace text field
What is a SMID?
The use of SMIDs ensures that every delta is uniquely identifiable, even if its SID is changed. A SMID is a number generated using the Xerox Secure Hash Function. When you use FreezePointing to create a freezepoint file, it calculates the SMID for both the current delta and the root delta in the SCCS history file. Using both of these values, FreezePointing can identify a delta in a file even if its SID has been changed. Why are SMIDs Necessary?
When Configuring encounters a file conflict during a Bringover Update transaction (file is changed in both the parent and child workspaces), it merges the new deltas from the parent workspace into the SCCS history file in the child. When this merge occurs, the deltas that were created in the child are moved to an SCCS branch off of the delta that both deltas have in common (common ancestor).
Note - This section briefly discusses how Configuring merges SCCS history files. For more information, see Chapter 11, "How the Configuring Program Merges SCCS Files.
SMID/SID Translation
In release 2.0 of TeamWare, SMID/SID translation is available only through the FreezePointing CLI. Translating SIDs to SMIDs
Use the freezept smid command to translate SIDs to SMIDs. The syntax is:
example% freezept smid -r 1.38 module.c SID 1.38 = SMID "f5b67794 705f0768 a89b1f4 588de104" |
Translating SMIDS to SIDS
Use the freezept sid command to translate SMIDs to SIDs. The syntax is:
Note - Because the SMID contains white space, you must enclose it within quotation marks.
example% freezept sid -m "64fdd0df de9d7dd de75812 23da96aa" module.c SMID "64fdd0df de9d7dd de75812 23da96aa" = SID 1.36 |