Details
-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Major
-
Resolution: Fixed
-
Component/s: subversion-plugin
-
Labels:None
-
Environment:Windows 7 x86_64, Jenkins 1.470, Subversion plugin 1.40
-
Similar Issues:
Description
Suppose we have SVN repository https://svnserver/rep1 with HEAD=3.
Test case:
1. Create Jenkins job (free-style build)
2. Check "This build is parameterized", add String parameter "REVISION"
3. Select "Source Code Management" = "Subversion", specify Repository URL = https://svnserver/rep1/trunk@${REVISION}
4. Save configuration, click "Build now", specify REVISION parameter with value=HEAD
5. Wait for build finish (it should succeed), click "Build now" again, specify REVISION parameter with value=2
Expected result:
Build succeeds with working copy in workspace at revision 2.
Actual results:
Build fails on working copy update step (full log attached):
Updating https://svnserver/rep1/trunk@2
U Test.java
At revision 2
hudson.util.IOException2: revision check failed on https://svnserver/rep1/trunk
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:170)
at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:112)
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:563)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:710)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1242)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494)
at hudson.model.Run.execute(Run.java:1460)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:239)
Caused by: org.tmatesoft.svn.core.SVNException: svn: E160006: No such revision 4
svn: E175002: REPORT of '/rep1/!svn/bc/3/trunk': 500 Internal Server Error (https://svnserver)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
...
Error is reproduced with different versions of Jenkins, Subversion plugin and different values of "Check-out Strategy" parameter.
Attachments
Issue Links
- is duplicated by
-
-
- Resolved
-
Activity
For reference:
this is the pull request https://github.com/jenkinsci/subversion-plugin/pull/17
kutzi
added a comment - For reference:
this is the pull request https://github.com/jenkinsci/subversion-plugin/pull/17 Code changed in jenkins
User: gmjck
Path:
src/main/java/hudson/scm/SubversionChangeLogBuilder.java
http://jenkins-ci.org/commit/subversion-plugin/9a460b806c2f3f3e33ee0b0204b82941c7213f74
Log:
[FIXED JENKINS-14116] Update to older revision
Added check to generation of change set between previous workspace
(prevRev) and current workspace (thisRev) to correctly handle case when
prevRev > thisRev. Change set covers commits [prevRev+1, thisRev], which
is backwards when updating to an older revision, resulting in an
incorrect summary and, if prevRev=HEAD, throwing exceptions and failing
the build since HEAD+1 does not exist. Solution: if prevRev > thisRev,
swap values before generating change set.
Code changed in jenkins
User: Christoph Kutzinski
Path:
src/main/java/hudson/scm/SubversionChangeLogBuilder.java
http://jenkins-ci.org/commit/subversion-plugin/ed8a1f80131f706328318774b61580b0acfccfac
Log:
Merge pull request #17 from gmjck/master
[FIXED JENKINS-14116] Allow going back to older revisions
Compare: https://github.com/jenkinsci/subversion-plugin/compare/fd79a2f7b421...ed8a1f80131f
The issue appears to be in SubversionChangeLogBuilder.java's buildModule() method, where it generates the change set between the workspace's existing revision and the revision you are checking out. The parameters that it passes to the SVN core are assuming that the existing workspace revision (prevRev @ line 139) is smaller than the revision being checked out now (thisRev @ line 144). The code accumulates all the change sets between prevRev+1 and thisRev. If, e.g., your workspace is at rev 100 and you checkout rev 110, this produces the changes for 101-110. But if you're going backwards, say from 210 to 200, you get the accumulated change sets from 200 to 211... one more change set than has actually been applied. This is misleading but not critical if revision 211 exists. But if 210 is the HEAD, you get the exceptions that Dmitry posted.
I think the following inserted at line 153 of SubversionChangeLogBuilder.java would take care of this:
if (prevRev.compareTo(thisRev) > 0) {
long temp = thisRev.longValue();
thisRev = new Long(prevRev.longValue());
prevRev = new Long(temp);
}
... cleaned up with whatever autoboxing Java is doing now, I'm a C guy these days.
Edit: pull request submitted.