• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • subversion-plugin
    • None
    • Platform: All, OS: All

      I often get an checksum error when hudson is performing an update. This is the
      error:

      org.tmatesoft.svn.core.SVNException: svn: Checksum mismatch while reading
      representation:

      However, I can check out the code using the command line version. I did some
      googling and see more reports about this problem around the web with no real
      solution.

      Now, my problem with hudson is, is the fact that this resulted in 200 failed
      builds before I could disable the build (as I committed the code just before I
      left the office). In a way I would classify this as an internal hudson error and
      now new builds should be attempted until either a new code change or a manual
      build is triggered.

          [JENKINS-4727] svn error results in 200 failed builds

          uncletall added a comment -

          Further info:

          • hudson 1.329
          • subversion repository 1.4.6 using file:/// access

          I manage to check out the code using the web server that is hosting the
          repository on https://localhost...

          uncletall added a comment - Further info: hudson 1.329 subversion repository 1.4.6 using file:/// access I manage to check out the code using the web server that is hosting the repository on https://localhost ...

          uncletall added a comment -

          It looks like the checksum bug has been fixed in the svnkit on 15-Sep-2009
          version 1.3.1. See: http://svn.svnkit.com/repos/svnkit/tags/1.3.1/changelog.txt

          Ofcourse, the question remains if Hudson should keep on retying the builds when
          an internal error during checkout occures.

          uncletall added a comment - It looks like the checksum bug has been fixed in the svnkit on 15-Sep-2009 version 1.3.1. See: http://svn.svnkit.com/repos/svnkit/tags/1.3.1/changelog.txt Ofcourse, the question remains if Hudson should keep on retying the builds when an internal error during checkout occures.

          dbacher1 added a comment -

          I experienced a similar issue recently when configuring a new subversion repository. I set up a build that polled subversion, but used a different DNS alias in the Hudson svn configuration than in the build svn configuration. The end result was that the build did not have svn credentials and when I noticed the problem later in the day (after returning from meetings), there were 200+ failed builds.

          I suppose this could be classified as just a user configuration issue, but the end result is not particularly user friendly.

          dbacher1 added a comment - I experienced a similar issue recently when configuring a new subversion repository. I set up a build that polled subversion, but used a different DNS alias in the Hudson svn configuration than in the build svn configuration. The end result was that the build did not have svn credentials and when I noticed the problem later in the day (after returning from meetings), there were 200+ failed builds. I suppose this could be classified as just a user configuration issue, but the end result is not particularly user friendly.

          szczepiq added a comment - - edited

          Oh yeah, the lovely checksum mismatch error... I realize that it is related to bug in svn, svn setup, svnkit, etc. so hudson is pretty much innocent. However, it would be great if the plugin detected this svn error and do the full check-out in such case. I know that svn plugin already does it for SVNErrorCode.WC_LOCKED and SVNErrorCode.WC_OBSTRUCTED_UPDATE.

          I fixed it in the plugin but need to do some more tests to make sure it is working.

          szczepiq added a comment - - edited Oh yeah, the lovely checksum mismatch error... I realize that it is related to bug in svn, svn setup, svnkit, etc. so hudson is pretty much innocent. However, it would be great if the plugin detected this svn error and do the full check-out in such case. I know that svn plugin already does it for SVNErrorCode.WC_LOCKED and SVNErrorCode.WC_OBSTRUCTED_UPDATE. I fixed it in the plugin but need to do some more tests to make sure it is working.

          szczepiq added a comment -

          For the 200+ failed build problem: in my team I set up the email ext plugin so that it does not spam in case of subsequent failing build.

          szczepiq added a comment - For the 200+ failed build problem: in my team I set up the email ext plugin so that it does not spam in case of subsequent failing build.

          I still have this problem with Jenkins 1.475 and SVN plug-in 1.42. Any update to this?

          David Humeniuk added a comment - I still have this problem with Jenkins 1.475 and SVN plug-in 1.42. Any update to this?

          dup2 added a comment -

          I can confirm this with Jenkins 1.478 and the subversion plugin 1.42. Very annoying, our builds take ages now as we have to checkout a new workspace every time.

          dup2 added a comment - I can confirm this with Jenkins 1.478 and the subversion plugin 1.42. Very annoying, our builds take ages now as we have to checkout a new workspace every time.

            Unassigned Unassigned
            uncletall uncletall
            Votes:
            4 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: