Working copy locked error after interrupted update leaves mixed revisions

Question

Error ContextAn interrupted svn update can leave the working copy in a locked state. Subsequent commands fail with Working copy 'path' locked until the lock is cleared. The documented svn cleanup command removes stale locks and resumes incomplete operations, but it does not force the working copy to a single revision.Unresolved BehaviorAfter running svn cleanup on a working copy that was interrupted mid-update, the lock error disappears. However, svn status may still show a mixture of base revisions across files and directories. The documentation states that cleanup does not discard local modifications or restore missing pristine files, but it is unclear whether cleanup also leaves the working copy intentionally at mixed revisions or whether an additional step is required to synchronize all entries to the same revision.ConstraintsThe working copy uses the SQLite-based wc.db administrative format (Subversion 1.7+). The client version supports svn cleanup but not the newer --remove-unversioned or --remove-ignored flags. Local modifications must be preserved.Does svn cleanup guarantee a uniform revision across the working copy after an interrupted update, or is a follow-up svn update required to achieve a single revision? If a follow-up update is required, does it risk overwriting local changes that cleanup preserved? Are there documented conditions under which cleanup alone cannot resolve the mixed-revision state?

Tasadduq Burney · Answer

Direct answerNo. svn cleanup removes stale locks and may resume some incomplete operations, but it does not guarantee that every file and directory in the working copy shares a single base revision after an interrupted update. A follow-up svn update (or svn update -r REV for a specific revision) is required to bring the working copy to a uniform revision.Why cleanup leaves mixed revisionsAn interrupted svn update can leave the SQLite wc.db with entries at different base revisions. svn cleanup is designed to clear locks and finish certain metadata-only operations; it does not contact the repository to fetch missing changes or to align revisions across the tree.Follow-up update and local modificationssvn update preserves uncommitted local changes by merging incoming repository changes into them. Overlapping changes are reported as conflicts (marked C in svn status) rather than silently overwritten. However, unresolved conflicts, obstructed nodes, or missing pristine files can prevent the update from completing cleanly.When cleanup alone cannot resolve the mixed-revision statePre-existing mixed revisions (before the interrupted update).Operations that cleanup cannot resume (e.g., incomplete tree changes).Locks held by another active Subversion process.Missing pristine files in .svn/pristine.Recommended stepsEnsure no other svn process is running on the working copy.Run svn cleanup to clear stale locks.Run svn update to synchronize to HEAD, or svn update -r REV if you need the revision the original update was targeting.Verify with svn info -R and svn status : no lock errors, no C, ~, or ! markers, and a consistent Revision across all entries.Resolve any conflicts reported by the update before committing.CautionsBack up the working copy before updating if local changes are important, especially with tree conflicts or obstructed versioned files.Do not forcibly remove a lock while another svn process is active; that can corrupt wc.db.Check flag support with svn help cleanup and svn help update for your installed client version.

Working copy locked error after interrupted update leaves mixed revisions

Error Context

Unresolved Behavior

Constraints

1 answer

Direct answer

Why cleanup leaves mixed revisions

Follow-up update and local modifications

When cleanup alone cannot resolve the mixed-revision state

Recommended steps

Cautions

Your perspective belongs here.

0 question comments