On Friday October 17, this site was moved to a new server, https://mw.hh.se. The original address will continue to work. Whithin a week or two this site will return to the original address. /Peo HH IT-dep

WG211/M17Steimann: Difference between revisions

From WG 2.11
Jump to navigationJump to search
Created page with "Transactional Editing: Giving ACID to Programmers - Friedrich Steimann Collaborative programming today mostly relies on version control systems such as Subversion or Git. Lo..."
 
(No difference)

Latest revision as of 15:41, 28 June 2017

Transactional Editing: Giving ACID to Programmers

- Friedrich Steimann

Collaborative programming today mostly relies on version control systems such as Subversion or Git. Locking is generally file-based; while locking files explicitly (pessimistic locking) is supported, programmers often rely on optimistic locking, and on merging for resolving edit conflicts. However, neither pessimistic locking nor merging are supported in such a way that the current version of a program is always consistent (i.e., that it compiles), even if each programmer makes sure that her local copy compiles before committing.

In this talk, I will propose how projectional editors can be enhanced to guarantee the “C” in the ACID properties of transactional databases for programs under version control. Using two-phase locking on the attributes of an ASG representation of a program, granularity is much finer than for file-based locking, promising high parallelism. Locks are computed by exploiting the consistency (or well-formedness) rules of a language, which are also used to make sure that each edit transaction leaves a consistent program in a consistent state. Since edit transactions are usually small, a collaboration experience not unlike that of contemporary collaborative authoring tools (such as Google Docs) can be achieved.