svn:mergeinfo: Overlap handling during concurrent merges

Goal

Investigate how Subversion records merge ranges when multiple merge operations target the same branch concurrently.

Background

Subversion’s merge tracking uses the svn:mergeinfo property, which stores revision ranges applied to a path. The current implementation lacks a documented policy for handling overlapping ranges that arise from concurrent merges.

Uncertainty

When two merge sessions update the same property in parallel, the updates may interleave, potentially overwriting or duplicating merge ranges. Aborted or partially applied merges can leave incomplete entries, and --record-only may introduce ranges that do not correspond to actual changes.

Questions

• What policy does Subversion apply when a mergeinfo range overlaps an existing range during a concurrent merge?
• Will the mergeinfo update be merged, overwritten, or ignored in such a scenario?
• Does Subversion provide any lock or atomic update mechanism to prevent race conditions on the svn:mergeinfo property?