Category: Version control

svn: Can’t convert string from native encoding to ‘UTF-8’

The error “svn: Can’t convert string from native encoding to ‘UTF-8′” suddenly made it impossible to update one of the projects on our staging servers. The project contains loads of file under SVN control, and several data directories which up to this time wasn’t svn:ignore’d. One of the files in one of these directories had norwegian letters in ISO-8859-1 in its filename (which didn’t work in the project anyhow, as it was something left around from earlier).

This single file borked svn from actually being able to update or do anything useful with the actual files under SVN control. When Subversion analyzed the directory structure to check which files it should attempt to update, it would just barf before seeing any files with the error message about the file name not being in UTF-8. You’d think it would be better to ignore errors for filenames that aren’t a part of svn and that you’re not trying to add, but there’s probably a good reason for this behaviour.

Anyways: The solution: delete the file. We didn’t use it anyway. There’s also a good chapter in the SVN Book about localization issues which contain information about how you can solve the issue by changing your active character set.

Post-commit hook failed with error output: .. and nothing more.

While getting the trac-svn integration up and running in one of our repositories tonight, I stumbled across this issue. Most links I found on Google said to try to run the post-commit script by itself under the same user, which worked just fine. Checked that all my paths were absolute paths to avoid assuming any CWD, but still nothing. After trying to minimize the problem I discovered that even with a post-commit-script of just environmental assignments, things were still failing. This nabble archived thread did however give a very important hint by Ryan Schmidt (who obviously has solved the post-commit problems for every single developer out there, if I were to judge by the number of times his name comes up. Awesome work, Ryan.):

Your post-commit must also begin with a line like “#!/bin/sh” and have its executable bit set.

Wow. Homer Simpson “Doh!”-moment right there. No #!/bin/bash (or #!/bin/sh) ment that SVN weren’t able to run the script with the proper interpreter. When running it from the command line, bash were already running of course, so it just assumed that it was a bash script .. and it were right.

Thanks Ryan, saved me a couple of hours tonight.

Adding an External SVN Resource With Tortoise SVN

Most of my projects are usually checked out at several different computers and several different operating systems. For Windows, there is The One SVN Client Above All Else, namely TortoiseSVN. As Christer and I’ve been working on an unnamed project lately, we’ve built up a set of resources in regards to basic functionality (user registration, user verification, access management, etc). These resources have become a small framework for a basic site, so I’ve adopted the set of files for several other projects. When using the “Framework” in other codebases, I still want to keep the framework versioned against the original SVN repository, so that if Christer commits his Überkool Must Have Feature v2.5 to the framework, I get all the magic with a single svn up.

The magical way ofdoing this is using the svn:external property to tell svn that you depend on an external repository. The property is set on the parent directory, and contains the value Directory RepositoryURL; i.e:

Property Value
svn:externals Framework https://svn.example.com/Framework/trunk/Framework
OtherRepository https://svn.example.com/OtherRepository/trunk/

To set a property using TortoiseSVN, right click on the parent directory (i.e. libs or whatever you prefer to call your directory of common code), and select “TortoiseSVN” and “Properties”. Click “Add” and select svn:externals from the pulldown menu. In the value field you simply add Framework https://svn.example.com/Framework/trunk/Framework. Close the dialogs and select SVN Update when right clicking on your libs directory. This will create a directory named Framework in libs and check out the svn repository to the directory.

If you want several repositories as external dependencies in the same directory, add each repository on a new line.

Voilá!

UPDATE: Erik Hansen adds:
In order for Tortoise to “Update” your local copy with the external files, you first need to commit the property change to the REPO before it will do that.

UPDATE: Harry asked:

How do I provide other usernames and passwords for the other repositories? If my memory serves me right, as long as you’ve checked out the resource previously with TortoiseSVN, it will remember your username and password. I’d like an update for this, tho, as I’ve not been able to test it myself at the present time.

UPDATE: Chris added:
If you want several repositories checked out as external sources, add each repository on a new line under the same svn:externals property. Each directory can only have one externals entry, but the property may contain several repositories as long as they’re each put on a new line.