I spent some time troubleshooting a Subversion failure. I created a new repository using CreateSvnRepo.ps1 and successfully fetched the contents using TortoiseSVN. I added some files and then tried to commit the changes, but I got this highly cryptic error message:

Error: Commit failed (details follow): 
Error: Authorization failed 

The causes of this generic error are many and varied. So googling did not pinpoint the problem. I tried turning authorization off in the conf\svnserve.conf. Same result.

Now that was really odd. I turned off authorization, but authorization was still failing for writes. After a bit of head scratching, I noticed this:


Thank you Notepad2! The character encoding was set to Unicode and svnserve.exe was choking silently on the encoding. Without a readable svnserve.conf, it was using defaults, which allow anonymous reads, but not writes. That’s why I was able to fetch the repository, but not write to it. Switching the character encoding to ASCII solved the problem. Here is the offending line in the PowerShell script:

“[general]`r`nanon-access=none`r`npassword-db=../../passwd`r`nrealm=Default`r`n” > $repoConfigFile

Once I updated the command to specify the character encoding, everything was good for creating new repositories too.

“[general]`r`nanon-access=none`r`npassword-db=../../passwd`r`nrealm=Default`r`n” | Out-File -filePath $repoConfigFile -encoding ASCII

You can grab the updated version of CreateSvnRepo.ps1 here.

Let me wrap up by saying that I like Subversion, but its failure modes leave something to be desired. It would have been more helpful to fail with an unreadable svnserve.conf than ignoring the file and using defaults. Even better would be if it understood Unicode configuration files.