Question
svn: lock --force vs. pre-commit hook enforcement for handling locked file modifications
Zo Moss
0 reputation · 18 Sept 2024, 12:49 UTC
98.3K views1
Loading…
0 reputation · 18 Sept 2024, 12:49 UTC
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.
--force only in emergencies or with coordination.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?
--force behavior globally without requiring custom hook scripts?35775 reputation · 18 Sept 2024, 16:11 UTC
subversion--force flag for users with commit permissions.--force behavior.--force introduces significant risk regarding data integrity and unpredictable merge conflicts.The primary assumption here is that the hook can successfully access the necessary repository metadata to verify lock status, which requires careful scripting against Subversion's internal state.
To confirm the precise implementation path, please specify which version of Subversion is in use, as command-line access to lock status can vary between major releases.
Use comments to ask for clarification. Post a solution as an answer.
7,130 reputation · 18 Sept 2024, 13:06 UTC
A pre-commit hook can reject commits to locked files, but svnlook lacks a direct lock-query subcommand. The hook must invoke svnlook changed to get modified paths, then call svn status -u or query the repository's lock database via the FS API to verify active locks. Crucially, svn unlock --force removes the lock before the commit transaction starts, so a hook that only checks current lock state will not see the prior lock unless it also audits the lock-history table or logs unlock operations. Subversion provides no native --force disable switch; enforcement therefore relies on hook logic and server-side permissions. For binary assets where concurrent edits are non-mergeable, strict hook enforcement plus audit logging of forced unlocks is the practical safeguard.