Team Features - Revision history

Tuukka Lehtonen: /* Conflict Resolution */

2011-09-01T15:25:13Z

Conflict Resolution

← Older revision		Revision as of 15:25, 1 September 2011
Line 56:		Line 56:
	== Conflict Resolution ==		== Conflict Resolution ==

	The ~~use cases~~ which need conflict resolution are:		The user stories which need conflict resolution are:

	* ~~[[UC:Show Conflicts]]~~		* As a user, I want to see conflicts between local and remote database
	* ~~[[UC:Override~~ and ~~Update]]~~		* As a user, I want to override my local changes and update from remote
	* ~~[[UC:Override and Commit]]~~		* As a user, I want to override remote changes with my own changes
	* ~~[[UC:Conflict Resolving]]~~		* As a user, I want to resolve incoming conflicts

	~~This is~~ a ~~difficult question which is studied here [https://www.simulationsite.net/wiki/index.php/VersionControl].~~

	== Current Publish All ==		== Current Publish All ==

Juha Kortelainen at 15:54, 28 January 2011

2011-01-28T15:54:45Z

← Older revision		Revision as of 15:54, 28 January 2011
Line 90:		Line 90:

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

			[[Category: Database Development]]

Toni Kalajainen at 10:40, 29 September 2010

2010-09-29T10:40:12Z

← Older revision		Revision as of 10:40, 29 September 2010
Line 7:		Line 7:
	== Concepts ==		== Concepts ==

	See [[Conceptual Model]].		See [[Database Conceptual Model]].

	The data is represented as a graph. Each graph is partitioned into subgraphs.		The data is represented as a graph. Each graph is partitioned into subgraphs.

Toni Kalajainen at 10:36, 29 September 2010

2010-09-29T10:36:33Z

← Older revision		Revision as of 10:36, 29 September 2010
Line 7:		Line 7:
	== Concepts ==		== Concepts ==

	See [[~~Conceptual_Model~~]].		See [[Conceptual Model]].

	The data is represented as a graph. Each graph is partitioned into subgraphs.		The data is represented as a graph. Each graph is partitioned into subgraphs.

Toni Kalajainen at 10:36, 29 September 2010

2010-09-29T10:36:25Z

← Older revision		Revision as of 10:36, 29 September 2010
Line 1:		Line 1:
	== Introduction ==		== Introduction ==

	Team features view ~~[http://www.simantics.org/wiki/index.php/Use_Cases]~~ 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.		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.

	[[Image:Team Features Deployment.png]]		[[Image:Team Features Deployment.png]]
Line 7:		Line 7:
	== Concepts ==		== Concepts ==

	See [~~https://www.simantics.org/wiki/index.php/~~Conceptual_Model].		See [[Conceptual_Model]].

	The data is represented as a graph. Each graph is partitioned into subgraphs.		The data is represented as a graph. Each graph is partitioned into subgraphs.

Toni Kalajainen: Created page with '== Introduction == Team features view [http://www.simantics.org/wiki/index.php/Use_Cases] is for exchanging data between working copy and remote server. We have more than one us...'

2010-09-29T10:33:18Z

Created page with '== Introduction == Team features view [http://www.simantics.org/wiki/index.php/Use_Cases] is for exchanging data between working copy and remote server. We have more than one us...'

New page

== Introduction ==

Team features view [http://www.simantics.org/wiki/index.php/Use_Cases] 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.

[[Image:Team Features Deployment.png]]

== Concepts ==

See [https://www.simantics.org/wiki/index.php/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.

[[Image:Team Features Graph.png]]

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

[[Image:Team Features Change Set.png]]

== 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> = ?

[[Image:synchronize.png]]

== 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 [https://www.simulationsite.net/wiki/index.php/VersionControl].

== 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.