Tersus: Modeling as a Team

Modeling as a TeamDate: Apr 8, 2009Understanding how models are maintained in the file systemMapping the model package hierarchy to a file hierarchyTersus 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:

models/A.trp

models/A/B.trp

models/A/C.trp

models/A/C/D.trp

models/A/C/E.trp

Note that the .trp files will only exist if the appropriate package contains at least one model.How do changes to the model affect the file hierarchyTo understand how changes to the model affect the file hierarchy, we shall assume the following:

Package B contains model b (the file B.trp contains a definition of b)

Package C contains model c (the file C.trp contains a definition of c)

Model b uses (contains) model c (the file B.trp contains a reference to c as part of the definition of b)

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 application changesSynchronizing 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:

Switch to the Tersus Modeling perspective (Window -> Open Perspective or Window -> Open Perspective -> Other...)

Stop the application server if running

Save the model if there are any unsaved changes

Switch to the Navigator view (Window -> Show View)

Right-click the [Application Name] project root and select Team -> Synchronize with Repository. The studio will open a Synchronize view (or switch to the Team Synchronizing perspective), and display the files containing differences.

There are 3 possible types of differences:

Conflicts (indicated by a double headed red arrow) - Files with changes originating both locally and in the repository, which should be resolved.

Incoming/Updates (indicated by a left blue arrow) - Files with changes originating in the repository (other modelers modeling), which should be copied locally.

Outgoing/Commits (indicated by a right gray arrow) - Files with changes originating locally (your new modeling), which should be copied to the repository.

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.
Resolving conflictsConflicts 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):

Double-click the file in the Synchronize view, to open a Text Compare editor, showing the differences between the local version (on the left), and the latest revision from the repository (on the right).

Scan the file for differences (you can use the Select Next/Previous Change view toolbar buttons), and check if any of the differences is marked as a conflict (each difference is marked as either a Conflict, Incoming, or Outgoing change indicated as an icon on the header row).

If none of the differences are marked as a conflict, continue to the next conflicted file.

If there are any conflicting differences, you will need to resolve them by either manually editing the file, discarding your changes (Override and Update context menu option), or overriding with your revision (Mark as Merged context menu option) - this requires a thorough understanding of .trp syntax, which is beyond the scope of this document.

If .timestamp and .timestamp.db are conflicted, do the following:

Select it and choose the Override and Update context menu option.

Switch back to your model, and make a change to your model, then save it.

It will now appear as an outgoing file.

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.Updating incoming changesTo update incoming changes do the following:

Switch to the Synchronize view.

Click the Update All Incoming Changes... toolbar button.

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.

Switch to the Repository Explorer view and click the Refresh all unmodified projects toolbar button, to make sure the latest models have been loaded from the file system - this step is vital and skipping it may cause model inconsistencies.

Switch to the Application Server view, start the application, and test it to make sure it is working as expected.

Stop the application server.

Committing outgoing changesTo commit outgoing changes do the following:

Switch to the Synchronize view.

Click the Commit All Outgoing Changes... toolbar button.

At the Commit Files dialog, enter a description of the changes you are committing, and click Finish.

A suggested modeling methodology for minimizing team-related issuesThe 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:

Each modeler should maintain his models in separate ("owned") packages (= separate files).

If a model is to be reused in multiple locations in the application (and possibly by other team members), it should be maintained in it's own package.

Consider the necessity of changing a reused model's id (moving or renaming the model, or any of the packages in its path), as this will cause changes in multiple files, some of which may "belong" to other modelers.

If the change of model id is deemed necessary, use the following method to avoid conflicts:

Before making the change of id, all team members should synchronize and update/commit as needed.
At this point all team members should be completely synchronized with the repository, and should make no additional change to the model.
The team member maintaining the model whose id is to be changed, should make the id change, and commit the change
All other team members should now update their copy again.
The team may now continue modeling.