chshand entering your Io password followed by
/bin/tcshIt'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
bashat the prompt after you've logged in to use that shell instead.
diff svnkey.pub authorized_keysshould 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.
cat svnkeyThis 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,EC66522DC2A016B1followed 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.
c: cd \temp "c:\Program Files\TortoiseSVN\bin\TortoisePlink.exe" firstname.lastname@example.org ls -l > xThe output of the command will be stored in the file x once TortoisePlink completes. Wait about a minute or so and type
dir xIf it shows a non-zero size, type
type xto see the contents. If there's an error message, hopefully it will give you some hints about how to fix the problem.
# skip commands specific to interactive sessions if this session is # not interactive if ( ! $?prompt ) goto EXIT if ( "$prompt" == "" ) goto EXITafter 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).
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.exewhere 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.exeYou can also set this in the environment variables if you know about such things.
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.
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
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.