Announcement

Collapse
No announcement yet.

Upgrade 1.9.4 to 1.9.5 (Ubuntu 14.04 LTS) leads to svn E200019 Version mismatch error

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Upgrade 1.9.4 to 1.9.5 (Ubuntu 14.04 LTS) leads to svn E200019 Version mismatch error

    After apt-get update/upgrade svn server and client were installed,
    but any svn operations leads to following error:

    svn: E200019: Version mismatch in 'svn_subr' (expecting equality): found 1.9.4, expected 1.9.5
    svn: E200019: Version mismatch in 'svn_delta' (expecting equality): found 1.9.4, expected 1.9.5
    svn: E200019: Version mismatch in 'svn_fs_util' (expecting equality): found 1.9.4, expected 1.9.5

    Any ideas how to fix it?
    Last edited by FoxyBOA; 01-29-2017, 01:40 PM.

  • #2
    I would uninstall all of the subversion components and then simply install them.

    Comment


    • #3
      I did. The same result. Any ideas if/what SVN module did I forget to uninstall?

      Comment


      • #4
        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.

        Comment


        • #5
          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?

          Comment


          • #6
            It was easy. Have to restart SVN server.

            Comment


            • #7
              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.

              Comment


              • #8
                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!

                Comment


                • #9
                  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.

                  Comment

                  Working...
                  X