svn: lock --force vs. pre-commit hook enforcement for handling locked file modifications

Constraint

Subversion's default behavior allows users with commit access to override file locks using --force when the lock owner is unavailable or unresponsive. This can lead to unexpected conflicts or data loss in environments where file integrity during concurrent edits is critical.

Two Approaches

1. Manual enforcement: Rely on team discipline to respect existing locks and use --force only in emergencies or with coordination.
2. Automated prevention: Implement a pre-commit hook script that rejects any commit modifying a locked file, regardless of user permissions.

Unresolved Decision

The repository needs a policy that balances operational flexibility with data safety. While Subversion documentation confirms --force capability exists, it does not specify whether repository-level hooks can intercept and block such operations before they complete. Should the team enforce lock compliance through administrative controls or accept the risk of forced commits?

Questions

• Can a pre-commit hook reliably detect and reject modifications to files that have an active lock, even when the committer is not the lock owner?
• Does Subversion provide native configuration options to disable --force behavior globally without requiring custom hook scripts?
• What is the practical impact on merge tracking and revision history when locks are bypassed versus when they are strictly enforced?