Condensation vs. version control systems draft

Software developers and engineers often use version control systems (VCS) such as git, hq, or subversion, to manage their project data and source code. Such systems offer versioning and traceability of modifications, as well as transactional synchronization of all data.

Condensation has many things in common with a distributed VCS. Like most VCS, Condensation uses immutable data structures to keep different versions. Both put data synchronization forward, and both use a merge function to combine two data states.

However, there are a few key differences between VCS and Condensation.

Target audience

VCS are built for a specific purpose and audience: software developers (or engineers) managing project data, primarily source code.

Condensation is very generic, and does not target any specific audience. A VCS could be built as application on top of Condensation, but Condensation can be used for many other applications as well.

Versioning

VCS typically keep all versions – a desired feature in software development – and store diffs rather than full versions, as long as this makes sense.

Condensation offers generic versioning, but does not specify how these versions are encoded or linked with each other. This is left for the application to decide and implement. Versions can be given up at any time.

Explicit vs. implicit commits

In most VCS, the user decides when to commit his work, i.e., store a new version. This is typically done in intervals of a few hours.

In Condensation, new versions implicitly appear whenever the data is stored. In autosave applications, this can take place several times per minute.

Merge conflicts

Most VCS use interactive merging. Upon a conflict, the merge process stops and forces the user to investigate before completing the merge.

Condensation requires the use of a conflict-free merge algorithm. Logical conflicts in the data do not result in technical conflicts, and can be solved later if necessary.