Amy and Bill are two developers working on a shared codebase via GitHub. They use pull requests, and have a CI server that verifies that their code bu

Git Workflow is Snapshot-Isolated

submited by

Style Pass

2024-12-23 23:00:05

Amy and Bill are two developers working on a shared codebase via GitHub. They use pull requests, and have a CI server that verifies that their code builds and all of their tests pass before they merge any code.

This is, in principle, intended to keep the codebase valid at all times. Anyone who pulls it down and checks out any commit should be able to run it and have all the tests pass.

Unfortunately, a CI check is insufficient for this goal: since git will merge a commit as long as there are no merge conflicts, the following sequence of events is possible:

On teams with enough code movement for it to be a problem, it's sometimes fixed by having a bot that asynchronously serializes all pull requests to make sure they all pass CI in aggregate.

Snapshot isolation is a transactional isolation level common in SQL databases. A "transactional isolation level" is a specification that describes to what extent transactions can observe the effects of other transactions that are running concurrently.

Speaking precisely, a history obeys snapshot isolation if: * every transaction can be assigned a read timestamp t_r and a write timestamp t_w such that t_r and t_w are globally unique, and a transaction can see exactly the writes of transactions whose write timestamps precede its read timestamp, and * no two committed transactions which are concurrent (meaning their [t_r, t_w] intervals intersect) have overlapping write sets. Additionally, if t_r = t_w for all transactions, the history is said to be serializable.