Skip to content

Write reference updates to disk in TransactionManager tests

Sami Hiltunen requested to merge smh-realistic-tests into master

We're moving towards logging file system operation of reference updates instead of the logical updates in #5793 (closed). First hurdle in doing so is to actually write the reference updates to the disk in TransactionManager's tests. Currently they are staged directly in the transaction. This won't eventually work with physical updates as log the updates to the reference files the transaction did, so they'd have to be present on the disk.

This also highlights some issues in the test setup. Some tests are staging directly invalid state in the transaction to assert the behavior. This would not happen in practice as all of the reference updates go through Git, and are recorded in the transaction through the reference transaction hook. As such:

  • We don't need to validate reference names in the transaction manager as Git has already done so. All of the reference updates are fed to the transaction through Git in practice.
  • We should not test reference verification failures by directly staging updates with wrong old OID. Git would already reject them as it is performing them in the snapshot. Instead, we update the relevant tests to trigger such scenarios more realistically by having a concurrent transaction change the reference.
  • In similar fashion, Git would already fail if a reference transaction contains a directory-file conflict. We remove such unrealistic test scenario. We update the tests that exercise file-directory conflicts created by different transactions to do so concurrently as could happen in reality.
  • We remove tests checking that branches only point to commits. It's not a requirement stemming from transaction manager, and Git will fail such updates in the snapshot already.
  • We remove test where the transaction attempts to point a reference to a non-existent object as Git would fail such an operation already in the snapshot. We adapt one of the tests to exercise an unreachable object in the snapshot being referenced and pruned concurrently which is a realistic scenario that could actually happen.
  • Functionality and tests around the lock clearing logic are removed. If the repository contains locks, the updates in the snapshot would already fail as Git hits the locks. #5848 will apply the reference updates directly without creating new locks in the repository, and #5737 will handle cleaning up existing stale locks from the repository.

With the test issues out of the way, we start writing the reference changes to the disk in the tests.

Part of #5847 (closed)

Edited by Sami Hiltunen

Merge request reports