Invalid option 'addressing logical'

While I'm pretty much an SVN novice, I've been using TortoiseSVN on Windows 7 for a couple of years now for my embedded projects. My current project does software development on the Windows system for a Cortex M4 embedded design and also uses a Raspberry Pi module connected to the embedded system for data logging purposes. I now find myself in a situation where I need to export a file from three different SVN repositories on the Windows system to the Raspberry Pi. The TortoiseSVN version is 1.9.4 and I configured the svnserve.exe to run as a Windows service (making sure the default port was unblocked by the firewall). When I try to export a file to the Pi from any of the repositories I get two error messages. The first - E170013 - indicates that the Pi cannot connect to the repository. However, the second - E125006 - states that the .\db\format file contains an invalid filesystem format option 'addressing logical'. The fact that SVN on the Pi can access the format file leads me to believe that svnserve.exe is providing access to the repository. In searching online I found that SVN 1.9 introduced FSFS which could cause compatibility problems so I checked the version on the Pi and it was 1.8.10. I upgraded the Pi to 1.9.5 but am still getting the exact same error messages. The last thing I found online was a posting that indicated a 1.9.5 client should work with a 1.9.4 server. I've been struggling with this for a couple of days now and am at a point where I don't know what to try next.  Can anybody point me in the right direction?  Thanks, Dave

Last updated 6 years ago

The general requirement for Subversion is that any client version can work with any server version. So it's the SVN server bits on your Windows box that need to be updated...

Hmmm... that answers one question but raises another - I installed SVN 1.9.5 on a "test" Raspberry Pi. The original that I was testing on was running 1.8.10 and that produces the same error messages. Regardless, I'll update the Windows version. For what it's worth, this is the output message:  pi@tapServerDev:~ $ svn export -r 1030 "svn://office/C:/Projects/TAP/Baseboard//TAP Software Design/System Software/TAP/TAP_OS/SVN/logInfo.xml" svn: E125006: Unable to connect to a repository at URL 'svn://office/C:/Projects/TAP/Baseboard/TAP%20Software%20Design/System%20Software/TAP/TAP_OS/SVN/logInfo.xml' svn: E125006: 'C:\Projects\TAP\Baseboard\TAP Software Design\System Software\TAP\TAP_OS\SVN\db\format' contains invalid filesystem format option 'addressing logical' pi@tapServerDev:~ $ svn --version svn, version 1.8.10 (r1615264)  compiled Apr 29 2016, 16:45:06 on arm-unknown-linux-gnueabihf 

That output definitely seems to indicate that the SVN installed on your "office" system is not running SVN 1.9. There could be 2 problems:  A. Your server system has a single installed Subversion in a single location and that Subversion is not running SVN 1.9. Not sure how the repository could be 1.9 format (officially format 7) but that's what's showing.  B. Your server has more than a single installed Subversion installed and the URL you are giving it is going to the wrong version and therefore failing.  Good hunting...

The output posted above (pi@tapServerDev) was from the Linux system which is the client in this case. The Windows 7 command line output of the version command is:  C:\>svn --version svn, version 1.9.4 (r1740329)  compiled Apr 24 2016, 15:40:35 on x86-microsoft-windows 

Search for more versions... The svnserve that is receiving the request is the wrong version... 

Everything is now working, but I'm somewhat confused as to why. The two Raspberry Pi boards that I have been using as clients are running 1.8.10 and 1.9.5. I just completed the upgrade of the Windows system (office) from the previous TortoiseSVN 1.9.4 to 1.9.5 and now both of the clients are working. The only thing I can think of that may have made a difference is I had to reboot Windows after the installation (something I hadn't done since long before configuring and starting svnserve.exe since the Windows system is normally running tests that can easily last longer than a week). BTW, I did check for another instance of svnserve but didn't find one. The Windows Services window showed only one active and a search of the hard drive showed only the one binary in the TortoiseSVN directory.  Regardless of what it was, I appreciate your taking the time and patience to help on this.  Dave

Dave, glad to help. By the way I might be able to explain the problem. You are using "svnserve" as a daemon (service). It's possible that when you upgraded SVN the old "svnserve" process was not stopped and therefore was still running the older SVN release version. A reboot would have cleared that old process out and, when the system started, it would have started the new "svnserve". Just a thought. Probably not a good thought: Windows goes out of its way to prevent running executables from having their files modified... but some installers know the way around that. So still possible.