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

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

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      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

        Attachments

          Issue Links

            Activity

            Hide
            kutzi 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?

            Show
            kutzi 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?
            Hide
            daniel_k Daniel Kleinert added a comment -

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

            Show
            daniel_k Daniel Kleinert added a comment - Yes, we append @$revision to the Repository URL.
            Hide
            kutzi 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?

            Show
            kutzi 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?
            Hide
            jck2 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.

            Show
            jck2 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.
            Hide
            kutzi 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.

            Show
            kutzi 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.

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: