Tersus models are maintained as an hierarchy of packages (see the Repository Explorer view). The packages are maintained as a hierarchy of folders and files in the project's models folder (see the Navigator view).Assuming application A has package A which contains packages B and C, and C contains packages D and E, then you should find the following file hierarchy:
Note that the .trp files will only exist if the appropriate package contains at least one model.
To understand how changes to the model affect the file hierarchy, we shall assume the following:
Most changes to model c (such as internal modeling, height/width ratio, shared properties in general), will be reflected as a change to file C.trp.Changes to model c which define it's use in b (such as element name, position or size in b, other local properties), will be reflected as a change to file B.trp.Changes to c's id (the complete path to the definition of c - A/C/c) which is caused by renaming c or changing its location (either by moving it to another package, or renaming either package C or A), will be reflected as a change to both C.trp (change of c's id shared property) and B.trp (change of c's refId local property) - note that the same rules apply to the renaming of slots (trigger/exit).
Synchronizing compares your local copy of the application with the one in the repository, taking into account changes made by you (locally) and by other modelers (in the repository) since the last time each folder/file has been updated from the repository (or shared/checked-out) and reports the differences.Synchronizing should be performed periodically to make sure both the repository and your local copy of the application are up-to-date.To synchronize, do the following:
There are 3 possible types of differences:
Note that the Synchronize view can be set to view any one of the three types through the view's Mode toolbar buttons (Incoming, Outgoing, Incoming/Outgoing, and Conflicts); regardless of the mode currently selected, conflicts appear in all modes.The differences found should be dealt with in the order they appear above, that is Conflicts, Incoming, Outgoing.Before you continue, it is recommended that you backup your project. This is especially true in cases where conflicts have been identified.
Conflicts occur when a file that you have changed locally, has also changed in the repository (i.e. another modeler has committed a revision to the file in the repository, after your previous synchronization).To resolve conflicts do the following for each conflicted file (except .timestamp and .timestamp.db):
If .timestamp and .timestamp.db are conflicted, do the following:
If all conflicted file are identified as having no conflicting differences, you may continue to the next stage, updating your local project with the latest revision, this will change all conflicted files to outgoing files.
To update incoming changes do the following:
When update is complete all files marked as incoming should be removed from the view, and resolved conflicted files should be converted to outgoing files.
To commit outgoing changes do the following:
The are a few, relatively simple rules which are suggested in order to minimize issues (such as conflicts) that arise when an application is modeled by multiple modelers:
For best results, use the Firefox browser..