Team Features

Introduction

Team features view is for exchanging data between working copy and remote server. We have more than one user working with Simantics workbench. Each user has her own working copy and uses the team features view to exchange data by publishing it to the remote server and fetching it from remote server.

Concepts

See Database Conceptual Model.

The data is represented as a graph. Each graph is partitioned into subgraphs. Graph is made of resources which can have statements about the relations between resources and literals.

When data is changed we get change sets and and graph revisions. Each change set is made of ordered set of operations which describe the changes between the two graphs. Change sets form a list of changes that describe the changes made to the working copy over time. Change set is made of operations:

• create resource
• add statement
• remove statement
• set literal
• delete literal

Data Exchange

Here we sketch how data exchange between working copy and remote server works. On remote server we have list of change sets. On local server we have list of change sets which up to point are common with remote server, change sets fetched from server and local change sets. These scenarios don't take conflict resolution into consideration.

Synchronize

We fetch all remote change sets that are not on local server. We let user choose which she wants to apply. Those of the non selected change sets that belong to the same subgraphs as the selected are added and presented to the user. Then the selected change sets are added in the same order as they are in the remote server. Then the local changes are applied and if an operation can't be made an operation which will fix the error is added to the local change set in question. If the local change sets contain same operations that a remote change sets which has been added they are removed i.e. if the same statement is added by a local changes the statement is removed from the local change set.

Publish

We let user choose which local change sets she wants to publish. We check that all the subgraphs the local changes modify are either not published or at the head in the remote server. The selected local change sets are moved after the last remote change set and applied to remote.

Simple Example

Assumptions:

• Resource never dies (there is no change set)-
• Resource never changes the partition it belongs to.
• Each change set contains only operations that have effect i.e. add/remove stm or add&add stm sequences have been removed.
• We know the last change set upto which the local and remote change sets are identical.

In the following figure change set operations are expressed as:

• create resource := <letter>
• add statement := <letter>,<letter>,<letter>
• remove statement := not used
• set literal := <letter> = <literal value>
• delete literal := <letter> = ?

Conflict Resolution

The use cases which need conflict resolution are:

• UC:Show Conflicts
• UC:Override and Update
• UC:Override and Commit
• UC:Conflict Resolving

This is a difficult question which is studied here [1].

Current Publish All

The change sets that have not been published are sent to remote server. The change sets preserve their identity and order. The change sets are applied to remote server head wihout any conflict resolution. If operation can not be applied it is skipped.

Current Synchronize All

The change sets that have not been synchronized are sent to local server. The change sets preserve their identity and order. The change sets are applied to local server head wihout any conflict resolution. If operation can not be applied it is skipped.

Development Phases

• When user presses incoming/outgoing button a tree representation of incoming/outgoing change sets is presented for user. The only information for a change set is its identity.

• The change sets list is modified to be a change set tree.

• A meta information is added to change sets (string at first).

• User can choose the change sets that will be fetched/sent. The change sets will be applied without any checks. Operations that can't be applied (modifying a missing resource) are silently descarded.

• Core won't accept an incoming/outgoing change sets if there is even one operation that can't be applied. Specifically if resource doesn't exist, it will not be created automatically.

• Information for user so that an user can make a selective incoming/outgoing operations intelligently.

• User can add (meta) information to outgoing operations.

• Conflict resolution i.e. checking before or after applying change sets that the result is semantically correct.