phacility/phabricator · error · PhutilArgumentUsageException

Unable to lock repository "%s": only repositories that suppo

Error message

Unable to lock repository "%s": only repositories that support clustering may be locked.

What it means

Thrown by `bin/repository lock` when a target repository's `supportsSynchronization()` returns false — in Phabricator only Git and Mercurial implement cluster synchronization; Subversion repositories do not. It is the second pre-flight guard (after the hosted check), rejecting repositories whose VCS type cannot participate in clustered write locking.

Source

Thrown at src/applications/repository/management/PhabricatorRepositoryManagementLockWorkflow.php:43

    $repositories = $this->loadRepositories($args, 'repositories');
    if (!$repositories) {
      throw new PhutilArgumentUsageException(
        pht('Specify one or more repositories to lock.'));
    }

    foreach ($repositories as $repository) {
      $display_name = $repository->getDisplayName();

      if (!$repository->isHosted()) {
        throw new PhutilArgumentUsageException(
          pht(
            'Unable to lock repository "%s": only hosted repositories may be '.
            'locked.',
            $display_name));
      }

      if (!$repository->supportsSynchronization()) {
        throw new PhutilArgumentUsageException(
          pht(
            'Unable to lock repository "%s": only repositories that support '.
            'clustering may be locked.',
            $display_name));
      }

      if (!$repository->getAlmanacServicePHID()) {
        throw new PhutilArgumentUsageException(
          pht(
            'Unable to lock repository "%s": only clustered repositories '.
            'may be locked.',
            $display_name));
      }
    }

    $diffusion_phid = id(new PhabricatorDiffusionApplication())
      ->getPHID();

View on GitHub (pinned to 5720a38cfe)

Solutions

  1. Exclude the SVN repository from the lock target list.
  2. For SVN maintenance, use other means (take the service down, disable pulls/pushes at the web layer) since cluster locking does not apply.
  3. Long term, migrate the SVN repository to Git or Mercurial if cluster operations are required.

Example fix

// before
$ ./bin/repository lock R1 R3   # R3 is Subversion
[1168] Unable to lock repository "rR3": only repositories that support clustering may be locked.

// after
$ ./bin/repository lock R1   # Git/Hg only
Defensive patterns

Strategy: validation

Validate before calling

# Filter by VCS before locking (exclude SVN repos from the target list)
for r in R1 R3; do vcs=$(./bin/repository list --output json | jq -r --arg r "$r" '.[] | select(.callsign==$r) | .vcs'); [ "$vcs" = git ] || [ "$vcs" = hg ] && ./bin/repository lock "$r"; done

Type guard

function supports_cluster_lock(PhabricatorRepository $repository): bool {
  return $repository->isGit() || $repository->isHg(); // supportsSynchronization() is true only for these
}

Prevention

When it happens

Trigger: Running `./bin/repository lock` against an SVN repository; passing a wildcard list that includes the one SVN repo in an otherwise Git/Hg install.

Common situations: Legacy installations still hosting SVN attempt cluster lock procedures during maintenance windows; automation iterates all repositories without filtering by VCS type.

Related errors


AI-assisted analysis of phacility/phabricator@5720a38cfe (2026-08-21). Data as JSON: /api/errors/dab8c2317f4b9603. Report an issue: GitHub.