Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-15881

svn revision check failed when checking out older revision after HEAD build

XMLWordPrintable

      When the last build was HEAD revision and the new build is an older revision the revision check will fail.
      The problem arises in https://github.com/jenkinsci/subversion-plugin/blob/master/src/main/java/hudson/scm/SubversionChangeLogBuilder.java#L161

      SVNRevision.create(prevRev+1)

      if prevRev == HEAD, prevRev+1 will be an invalid revision

      hudson.util.IOException2: revision check failed on https://XXX
      at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:170)
      at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:112)
      at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:564)
      at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:713)
      at hudson.model.AbstractProject.checkout(AbstractProject.java:1308)
      at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:676)
      at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
      at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:581)
      at hudson.model.Run.execute(Run.java:1516)
      at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      at hudson.model.ResourceController.execute(ResourceController.java:88)
      at hudson.model.Executor.run(Executor.java:236)
      Caused by: org.tmatesoft.svn.core.SVNException: svn: E160006: No such revision 37
      svn: E175002: REPORT of '/XXX/!svn/bc/36': 500 Internal Server Error (https://XXX)
      at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
      at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
      at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLocationsImpl(DAVRepository.java:1066)
      at org.tmatesoft.svn.core.io.SVNRepository.getLocations(SVNRepository.java:1088)
      at org.tmatesoft.svn.core.io.SVNRepository.getLocations(SVNRepository.java:1516)
      at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178)
      at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:44)
      at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
      at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
      at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
      at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221)
      at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292)
      at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:967)
      at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
      at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:158)
      ... 11 more
      Caused by: svn: E160006: No such revision 37
      at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
      at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
      at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
      at org.tmatesoft.svn.core.internal.io.dav.handlers.DAVErrorHandler.endElement(DAVErrorHandler.java:72)
      at org.tmatesoft.svn.core.internal.io.dav.handlers.BasicDAVHandler.endElement(BasicDAVHandler.java:103)
      at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)
      at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
      at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2938)
      at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
      at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
      at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
      at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
      at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
      at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
      at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
      at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
      at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:796)
      at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:761)
      at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readError(HTTPConnection.java:228)
      at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.readError(HTTPRequest.java:290)
      at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:213)
      at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:385)
      at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:298)
      at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:289)
      at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:277)
      at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:696)
      at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:328)
      at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:318)
      at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLocationsImpl(DAVRepository.java:1060)
      ... 23 more
      Caused by: svn: E175002: REPORT of '/XXX/!svn/bc/36': 500 Internal Server Error (https://XXX)
      at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
      at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189)
      at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141)
      at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.createDefaultErrorMessage(HTTPRequest.java:444)
      at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.readError(HTTPRequest.java:288)
      ... 32 more

          [JENKINS-15881] svn revision check failed when checking out older revision after HEAD build

          kutzi added a comment -

          How do you manage do build an older revision in a later build? Do you pass the revision as a build parameter?

          kutzi added a comment - How do you manage do build an older revision in a later build? Do you pass the revision as a build parameter?

          Daniel Kleinert added a comment -

          Yes, we append @$revision to the Repository URL.

          Daniel Kleinert added a comment - Yes, we append @$revision to the Repository URL.

          kutzi added a comment -

          I - or any other Jenkins developer - could fix this single error, but I wonder if Jenkins would crash (or react weirdly) at some other place then. I mean, what you're doing could be considered as an unsupported use case: usually builds only go forward in svn history, newer builds have always the same or higher revisions as the previous one. Alone the concept of a changelog for this build: what should it contains? The negation of revision N (if N is the revision of the previous build)? Who should be notified (if we have email notification or that like), if going back to the previous revision breaks the build (again)?
          I think this is a good question for the developers mailing list.

          I wonder what the real world usecase of going back to an earlier revision is. Can you explain?

          kutzi added a comment - I - or any other Jenkins developer - could fix this single error, but I wonder if Jenkins would crash (or react weirdly) at some other place then. I mean, what you're doing could be considered as an unsupported use case: usually builds only go forward in svn history, newer builds have always the same or higher revisions as the previous one. Alone the concept of a changelog for this build: what should it contains? The negation of revision N (if N is the revision of the previous build)? Who should be notified (if we have email notification or that like), if going back to the previous revision breaks the build (again)? I think this is a good question for the developers mailing list. I wonder what the real world usecase of going back to an earlier revision is. Can you explain?

          J K added a comment -

          One of our products is a mesh networking device comprised of three microprocessors, each of which maps to a different development team, each of which maintains their own SVN repo and such. Our team is using Jenkins to manage a CI process with build management and unit testing (all specific to our microprocessor), but also integration testing and release management. The integration testing involves pulling and building the code for all three processors and deploying it into a testbed environment that runs automated tests taking anywhere from a few minutes to a few days depending on needed scope. Generally we want to pull from the head of trunk for all three projects.

          However, there have been times when the independent teams get into a state where there would be incompatibilities running the most recent code for all three. For instance, if the highest priority for teams A and B is to get a new interprocessor communication protocol working, but for team C is to get a mesh networking component ready, then trunk@HEAD processor C can no longer talk with trunk@HEAD A or B. When this happens we've used the ability to go back revisions on A and B to do integration testing and (internal) release management when our systems test (human-driven) resources were available.

          I created a groovy script that monitors SVN commit comments for certain key word/value pairs, one of which specifies if a particular revision of processor A and/or B code is needed. This, plus the patch I submitted on github for issue #14116, took care of the problem. We're still quite new to Jenkins and CI in general, so there may be a more elegant solution. But so far this has been working for us.

          J K added a comment - One of our products is a mesh networking device comprised of three microprocessors, each of which maps to a different development team, each of which maintains their own SVN repo and such. Our team is using Jenkins to manage a CI process with build management and unit testing (all specific to our microprocessor), but also integration testing and release management. The integration testing involves pulling and building the code for all three processors and deploying it into a testbed environment that runs automated tests taking anywhere from a few minutes to a few days depending on needed scope. Generally we want to pull from the head of trunk for all three projects. However, there have been times when the independent teams get into a state where there would be incompatibilities running the most recent code for all three. For instance, if the highest priority for teams A and B is to get a new interprocessor communication protocol working, but for team C is to get a mesh networking component ready, then trunk@HEAD processor C can no longer talk with trunk@HEAD A or B. When this happens we've used the ability to go back revisions on A and B to do integration testing and (internal) release management when our systems test (human-driven) resources were available. I created a groovy script that monitors SVN commit comments for certain key word/value pairs, one of which specifies if a particular revision of processor A and/or B code is needed. This, plus the patch I submitted on github for issue #14116, took care of the problem. We're still quite new to Jenkins and CI in general, so there may be a more elegant solution. But so far this has been working for us.

          kutzi added a comment -

          Thanks for describing your use case.
          If that works for you (with the patch), then fine.
          I would propose to use the artifacts of a previous build which already build the previous revision, again.
          One principle in CI says that you should only build the artifacts once.
          But again: if it works for you fine and I don't see any strong reasons against including the pull request in JENKINS-14116. So I'm going forward to merge it.

          kutzi added a comment - Thanks for describing your use case. If that works for you (with the patch), then fine. I would propose to use the artifacts of a previous build which already build the previous revision, again. One principle in CI says that you should only build the artifacts once. But again: if it works for you fine and I don't see any strong reasons against including the pull request in JENKINS-14116 . So I'm going forward to merge it.

            kutzi kutzi
            daniel_k Daniel Kleinert
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: