Subversion Help: Frequent problems and solutions

Robert W. Hasker

Possible problems with Subversion at UWP and things to fix

Note this focuses on things that are fixed by changing settings in Subversion. Sometimes the problem is with your Unix (or Linux) setup, so if you don't see a solution to your problem here you might also check out the

Contents:

Things Just Not Working: no response at all
Common Error Messages: what to do with error messages people run into frequently
Common Issues: common problems/issues and how to solve them.
Other Subversion Links

Things Just Not Working

If you're not getting any sort of response from TortoiseSVN, try the following:

If your shell on Io is set to bash, change it to tcsh by typing
```
        chsh
```
and entering your Io password followed by
```
        /bin/tcsh
```
It's not clear why bash is incompatible with TortoiseSVN, but for the moment changing the shell is the simplest solution. You can always simply type
```
        bash
```
at the prompt after you've logged in to use that shell instead.
Log in to io.uwplatt.edu, type "cd .ssh", and type "ls -l". You should see three files: authorized_keys, svnkey, and svnkey.pub. More importantly, compare the numbers just before the dates; this column contains the size of each file in bytes. The files svnkey.pub and authorized_keys should have the same size. Typing
```
        diff svnkey.pub authorized_keys
```
should print nothing. If it does print something, you probably copied svnkey to authorized_keys; repeat the step
```
        cp svnkey.pub authorized_keys
```
(answering yes when asked to overwrite authorized_keys). Then try again.
If the files look the same, make sure you have the right type of key. Type
```
        cat svnkey
```
This prints the contents of the svnkey file on the screen. You should see something starting with
```
    -----BEGIN RSA PRIVATE KEY-----
    Proc-Type: 4,ENCRYPTED
    DEK-Info: DES-EDE3-CBC,EC66522DC2A016B1
```
followed by several lines of apparently random characters. If the file says "DSA" or "RSA1" on the first line instead, you'll need to redo the above steps to generate the public and private key pairs.
One way to test that your key works is to run TortoisePlink from the command line. Start a DOS prompt and type
```
    c:
    cd \temp
    "c:\Program Files\TortoiseSVN\bin\TortoisePlink.exe" username@io.uwplatt.edu ls -l > x
```
The output of the command will be stored in the file x once TortoisePlink completes. Wait about a minute or so and type
```
    dir x
```
If it shows a non-zero size, type
```
    type x
```
to see the contents. If there's an error message, hopefully it will give you some hints about how to fix the problem.
Try updating the TortoiseSVN client.

Common Error Messages

Some frequent error messages and what to do about them. If you don't see yours on this list, send email to Dr. Hasker or check out the online book. Note the messages might not match exactly!

An error of the form "Can't copy 'J:\proj\somefile.xyz' to j:\proj\.svn\temp\text-base\somefile.xyz-svn-base.tmp': There is not enough space on the disk." This usually means you've run out of space on your J: drive. You will need to delete some files and then retry the operation.
"Unable to write to standard output (stderr)". One reason this can happen is adding the line "mesg n" or "mesg y" to your .cshrc file. The solution is to only execute the mesg command if you're at a login shell; that is, add the code
```
# skip commands specific to interactive sessions if this session is
# not interactive
if ( ! $?prompt      ) goto EXIT
if ( "$prompt" == "" ) goto EXIT
```
after the code to set the path variable, and then add
```
EXIT:
```
at the end of the file. Then you can add the mesg command after the second if (the check that $prompt is empty).
"svn: Can't create tunnel: The system cannot find the file specified."
This is typically caused by Subversion not being able to access the "plink" command which is responsible for the low-level transport across SSH. If you're using TortoiseSVN, open the Settings menu, click on the Network icon, and make sure "SSH client" is set to the path for "TortoisePlink.exe". If you're using subversion at the command-line (DOS) prompt,
```
        set SVN_SSH=path/plink.exe
```
where path is that path to your copy of plink (which you can retrieve from the same place as PuTTY - just type the name into your favorite search engine) with forward slashes For example, if your copy of plink is in c:\apps\plink.exe, you'd execute
```
        set SVN_SSH=c:/apps/plink.exe
```
You can also set this in the environment variables if you know about such things.
"Failed to add file '(name here)': object of the same name already exists.
or
"Can't open file 'folder\.svn\tmp\text-base\file.svn-base': The system cannot find the file specified."
Both mean that two files in the same folder have the same name except for capitalization; for example "Readme.txt" and "README.TXT". Unix and Subversion are case-sensitive, so the files are considered to be completely unrelated. But in Windows is not case-sensitive, so when it tries to update README.TXT on top of Readme.txt (say), it breaks.
The surest way to fix the problem is to log in to a Unix system (such as io.uwplatt.edu) and use the unix notes to check out the repository there. You can then use the svn mv command to rename one of the files. If you are in the middle of trying to add a file to your repository, you might try using TortoiseSVN->Rename... to rename the existing file to something entirely different and then updating. Note that you need to use the TortoiseSVN rename commands; merely renaming the file in Windows Explorer won't fix your problems.
You're getting error messages about files being out of date when trying to commit, but update operations fail. This is often caused by trying to check in changes to (modified) files when you've also moved those files between folders or - worse yet - trying to check in changes to files in folders that have been renamed/moved within subversion. The basic fix is to copy the changed files to a new location - and make sure the copy succeeded or you'll lose work!, delete the files that are keeping updates from working, completing the update, and then move the modified versions of the files to the appropriate places. You'll now be able to check in your modifications.
An extreme form of this problem is when you try to update a file that's been deleted in the repository or add a file to a repository when that file was added by someone else. Again, you can often get around these problems by moving your changed files somewhere safe, getting your local repository up-to-date, and then moving the changed files back. A solution that can also work - though has to be used carefully - is to use the subversion delete operation to delete the offending file from the repository, update everything, commit the changes, then re-add the file to the repository (based on the copy you made earlier).
One frequent gotcha with Subversion is trying to make too many changes at the same time. If you rename files or (even more so) rename a folder or move a file between folders, be sure you commit those changes before changing the files themselves. In general, don't mix operations
You get the message "Connection closed unexpectedly" when trying to use TortoiseSVN either to check out a repository or to update one. This message appears for a variety of reasons, most often because your network connection was dropped. A more obscure reason is having set a host name in your default session for PuTTY. To check on this, do the following:
1. Start putty.
2. Select "Default Settings" and click on Load. If the Host Name box is filled in, continue:
3. Delete the contents of the Host Name box
4. Click on the Save button.
We're not clear on why PuTTY's settings would be causing problems for TortoiseSVN!
TortoiseSVN complains that the local copy was created by a newer version and so the copy cannot be updated. Certain versions of TortoiseSVN are incompatible with others, and so they can't both process the same checked-out folders. There are several couple of solutions:
- Switch to a matching version of TortoiseSVN, if possible. Old versions are available at http://tortoisesvn.tigris.org/.
- Check out to another location, for example the C: drive (unless you're in a lab) or simply another folder on your J: drive.
- If you know that everything has been checked in, delete the out-of-date copy and re-check out a new copy.
The second choice is probably the best one. It's perfectly ok to check out a repository on the same file system twice.
The tool doesn't respond to commands the way you expect. Double-check that you don't have TortoiseCVS instead of TortoiseSVN. The two tools share some commonality, but they're essentially incompatible.

Common Issues/Problems (with solutions)

Locking Files: Subversion's general model is to allow multiple people to edit a file and depend on merging to resolve conflicts. Many files fit this model well: they are either text and so can be merged (such as code) or they're modified infrequently enough that conflicts rarely occur. However, it would be good to be able to "lock" certain files so that only one person can edit them at a time. Subversion also supports this type of file locking, and this item describes how to lock files.
The first step is to indicate to Subversion that the file needs to be locked. To do this in TortoiseSVN, right click on the file name and select "Properties" from the TortoiseSVN menu. Click on the Add... button and select "svn:needs-lock" from the Property name: menu. Click on the OK button for the add dialog, and then click on OK again for the Properties dialog. At this point you need to commit the changes to the file; this will make the file read-only (which you can confirm by looking at the Properties dialog in Windows Explorer).
Once the file is marked as needing a lock, to edit the file select "Get lock..." from the TortoiseSVN menu. When you are finished making changes, simply commit the file and the lock will be released. You can also use "Release lock..." from the TortoiseSVN menu, but doing that if you've made changes is unwise. Note that you can steal a lock using the "Get lock..." dialog, but doing so is dangerous. If you do steal a lock, be sure to email the original locker so he or she understands what happened.
I can't commit and I can't update. That is, Subversion says you must update before committing, but updates fail. This is often caused by trying to commit too many changes at one time, but can be caused by other problems as well. The fix is to get the files into the Ullrich 207 lab where you can use Beyond Compare to patch things up:
1. If necessary, copy the entire folder with problems in it to your J: drive, or in some way copy the folder to a machine in the Ullrich 207 lab.
2. In the Ullrich 207 lab, check out the repository to a different directory.
3. Right click on the broken version of the repository and select "Select Left Side to Compare".
4. Right click on the "clean" repository and select "Compare to XXX" where XXX is the name of the broken copy. Beyond Compare will compare the files and show you which files were changed.
5. Expand directories to find the changed files. Do not expand any of the .svn directories - any changes in those files must be ignored.
6. Beyond Compare provides operations to copy changed files from the broken repository to the clean one. You can also view changes in individual files by double-clicking on each; the viewer also provides operations to copy changes from one version of the file to the other.
7. You can then simply commit the changes from the clean repository. But don't delete the broken one until you're sure all desired changes have been committed!