Skip to content

TortoiseSVN Problems and Solutions

Reference notes covering the SVN issues and commands discussed during setup of the UCalgary Baja SVN working copy.

Repository URL:

http://100.64.0.3:9095/svn/baja_current

1. Error: “Repository temporarily moved to …”

Problem

TortoiseSVN reports that the repository was temporarily moved. This normally means the SVN URL is returning an HTTP redirect instead of the expected Subversion response.

Typical redirects include:

HTTP/1.1 301 Moved Permanently
Location: http://100.64.0.3:9095/svn/baja_current

or:

HTTP/1.1 302 Found
Location: http://100.64.0.3:9095/login

Common causes

  • Using an SVNAdmin/web-interface URL instead of the actual repository URL.
  • HTTP being redirected to HTTPS.
  • A missing trailing slash causing a redirect.
  • A reverse proxy such as Nginx Proxy Manager redirecting the request.
  • An authentication portal intercepting the SVN path.
  • The Apache SVNParentPath or Location not matching the checkout URL.

Test the URL

curl -I "http://100.64.0.3:9095/svn/baja_current"

Look for a 301, 302, or Location: header.

You can also test the repository directly with SVN:

svn ls "http://100.64.0.3:9095/svn/baja_current"

If svn ls works but TortoiseSVN does not, use the exact same repository URL in TortoiseSVN.

2. Supplying a Username and Password

TortoiseSVN normally asks for credentials automatically when the SVN server requires authentication.

If the wrong credentials were previously saved, clear them using:

TortoiseSVN → Settings → Saved Data → Authentication data → Clear

Then retry the SVN operation and enter the correct username and password.

Command-line authentication test

svn ls "http://100.64.0.3:9095/svn/baja_current" --username "John Smith" --password "YourPassword"

Avoid embedding credentials directly in the URL, such as http://user:password@100.64.0.3:9095/svn/baja_current, because they can be exposed in logs or shell history.

3. Checkout Repository to C:\UCBaja

Use:

svn checkout "http://100.64.0.3:9095/svn/baja_current" "C:\UCBaja" --username "John Smith" --password "YourPassword"

If you want the operation to avoid interactive prompts:

svn checkout "http://100.64.0.3:9095/svn/baja_current" "C:\UCBaja" --username "John Smith" --password "YourPassword" --non-interactive

If svn ls already works, use that exact same repository URL for checkout.

4. Are the Credentials Saved?

By default, the Subversion command-line client caches successful authentication credentials unless --no-auth-cache is used or authentication caching has been disabled in the SVN configuration.

After a successful authenticated checkout, future commands can normally be run without supplying the password again:

svn update "C:\UCBaja"

svn commit "C:\UCBaja" -m "Updated files"

Cached SVN authentication information can be inspected with:

svn auth

TortoiseSVN and a command-line SVN client often use compatible Subversion authentication storage, but this should be tested on the exact Windows/TortoiseSVN installation if automatic workstation provisioning depends on it.

5. Working Copy Is Locked

Problem

SVN reports that the working copy, or a directory inside it, is locked because an earlier SVN operation was interrupted or did not finish cleanly.

Solution

svn cleanup "C:\UCBaja"

Cleanup operates recursively through the working copy and clears SVN working-copy administrative locks in subdirectories as well.

These working-copy locks are different from repository file locks created with svn lock.

6. Repository File Locks

If a file was explicitly locked using SVN's lock-modify-unlock workflow, use svn unlock rather than svn cleanup.

Example:

svn unlock "C:\UCBaja\path\to\file.SLDPRT"

If an administrator or authorized user needs to break another user's repository lock:

svn unlock "C:\UCBaja\path\to\file.SLDPRT" --force

Use --force carefully because it can remove another user's active lock.