Fix SVN Working Copy Locked Error

Step‑by‑step guide to diagnose and resolve the Subversion 'working copy is locked' error (svn: E155007) during commits.

Recognizable condition

When you run svn commit (or other write operations) the command fails with:

svn: E155007: Working copy is locked
svn: E155007: Failed to add file 'path/to/file.txt': working copy locked

The message indicates that a lock file in the working copy’s .svn directory is preventing further SVN activity.

Possible cause	Typical symptom
Previous SVN operation terminated abruptly (e.g., Ctrl‑C, kill)	A `.svn/lock` file remains in the working copy root
Manual deletion of `.svn/lock` while another SVN process ran	Lock file may reappear or working copy becomes inconsistent
NFS stale file handles	Lock appears even though no SVN process is visible; `ls -l .svn/lock` shows a stale inode
Antivirus or backup software scanning the `.svn` directory	File‑access delays cause SVN to think the lock is held

Run svn status --show-updates from the working copy root. Look for an L flag beside any path, which signals a lock.
```
# Run where you have read/write access to the working copy
svn status --show-updates
```

Check for the physical lock file:

# Replace <wc-path> with your working copy root
ls -la <wc-path>/.svn/lock 2>/dev/null || echo "lock file not found"

Verify no SVN client processes are holding the lock:

# Requires permission to list processes; run as your user or with sudo if needed
lsof | grep "\.svn/lock" || echo "no SVN process using lock"

Confirm the underlying filesystem supports locking:

# On Linux, check if the mount is local or NFS
mount | grep "^<wc-path>" | grep -i nfs && echo "NFS mount detected" || echo "local or other FS"

Lock file present and no SVN process: Run the built‑in cleanup command.
```
# Run from the working copy root; needs write permission
svn cleanup
```
If cleanup succeeds, the .svn/lock file is removed and you can retry the commit.
Cleanup fails or lock persists: Ensure no SVN process is running (repeat step 3 above), then manually delete the lock file.
```
# Only after confirming no SVN process uses the lock
rm -f <wc-path>/.svn/lock
```
After removal, run svn cleanup once more to clear any ancillary lock files (e.g., .svn/wclock).
NFS stale handle: Remount the share with the noac attribute to disable attribute caching, or move the working copy to a local disk.
```
# Example remount (requires root)
mount -o remount,noac <nfs-share> <wc-path>
```
Antivirus interference: Add an exclusion for the .svn directory in your AV product, then retry the operation.

Run the command that originally failed, e.g., svn commit -m "fix".
Confirm it completes without error and a new revision number appears in the output.
Check that no lock files remain: find <wc-path> -name lock -type f should return no results.
Optionally, run svn info to see the updated revision.

If lock files reappear immediately after manual removal or cleanup, or multiple lock files (.svn/lock, .svn/wclock, .svn/log) are present, the working copy may be corrupted.
In that case, check out a fresh working copy: svn co <repo-url> <new-dir> and migrate any uncommitted changes manually.
If the repository itself reports lock errors (e.g., running svnadmin look on the DB shows stale logs), contact the repository administrator to run svnadmin recover on the repository path.