DougR
I would uninstall all of the subversion components and then simply install them.
FoxyBOA
I did. The same result. Any ideas if/what SVN module did I forget to uninstall?
DougR
You should look for both "svn" and "subversion". This means something like: apt list | awk '{print $1}' | egrep 'svn|subversion' | less You're going to need to remove them all before trying to re-install.
FoxyBOA
Unfortunately, no luck. > apt list --installed | awk '{print $1}' | egrep 'svn|subversion' | less I added (--installed) flag to above command. Shows me (as I expected): > libsvn1/now > subversion/now Remove, reinstall and got the same result. Could I use broken binary distribution?
FoxyBOA
It was easy. Have to restart SVN server.
DougR
That's really weird. A reboot that results in resolving that problem may point to file system corruption. I would take the box down and run fsck in verbose mode. If it finds errors then give it the "-y" option on a 2nd run. Capture the screen output to a different system so you can review it later.
FoxyBOA
I believe that the situation is a bit different: - My svn server is starting via init.d (my own custom script cause binary package doesn't have one) - I use to "apt-get upgrade" correctly restart init.d services (and I forgot that not in this case) - svnserve loaded libs in memory (1.9.4) - "apt-get upgrade" change binary on disk (1.9.5 - svn binary and libs) - restart svnserve (i.e. my init.d script) leads to loading correct version of libs in memory When I execute any svn commands until server restart it use preloaded version of 1.9.4 libs and I've got an exception Than you for your assistance!
DougR
Shared libraries are loaded into a process space by following file system paths that are connected to specific inodes that are pointed to by directory entries. The upgrade should have unlinked the running inodes (that's fine) and linked in new inodes to contain the new file versions. Running a new executable should have found the new inodes, not the old inodes. Just because something is "in memory" does not mean it will be used. The error message: svn: E200019: Version mismatch in 'svn_subr' (expecting equality): found 1.9.4, expected 1.9.5 Means that the *new* svn command (version 1.9.5) found the *old* svn library version on-disk. That means that the old library versions had not been replaced on-disk by apt-get and that there was a mis-matched set of executables/shared-libraries. That should not have happened. You're right: when you rebooted the "svnserve" process would be killed. But it may have fixed up something broken in your file systems (I'd check the syslog/messages log files). And I'd double-check the file system sanity by running a full fsck. But that's me.