Repository navigation
[JENKINS-856] Subversion change list only lists first change since last revision #409
Description
In the latest version (and all recent versions I've seen) of Hudson, the
subversion change list only lists 1 change per directory checked out by hudson,
regardless of how many changes there were. It always only shows the first
change since the last build's revision.
I investigated and I believe this is due to a bug (or at least an inconsistency
in the docs/typing) in svnkit (so I marked this as a PATCH not BUG for hudson)
and I created a patch file as a workaround for my own use. I'm not sure how to
attach it, in case anyone else has this problem...which I assume anyone on 32
bit systems using subversion+hudson has. It's just a matter of changing the
call to SVNLogClient.doLog() to pass 0 instead of Long.MAX_VALUE.
I believe problem is a combination of svnkit not documenting (well enough)
proper use of the limit parameter (which is a long) in SVNLogClient.doLog, and
some int/long weirdness along the way to subversion itself. As it turns out, on
32bit systems the subversions max revision is 2^32-1, not 2^64-1
(Long.MAX_VALUE) ... so when svnkit passes this to subversion, I believe it's
overflowing and only returning a single change to svnkit (and then to hudson).
Passing 0 instead of Long.MAX_VALUE is consistent with the rest of svnkit's log
limit requests, and results in it not adding a limit tag to its request to
subversion (proper behavior). I may not be 100% correct on the explanation, but
this definitely remedies a serious issue for me.
Originally reported by jmmckinnon, imported from: Subversion change list only lists first change since last revision
- status: Closed
- priority: Major
- component(s): subversion-plugin
- resolution: Fixed
- resolved: 2007-11-14T14:34:32+00:00
- votes: 0
- watchers: 0
- imported: 20251212-090250
Raw content of original issue
In the latest version (and all recent versions I've seen) of Hudson, the subversion change list only lists 1 change per directory checked out by hudson, regardless of how many changes there were. It always only shows the first change since the last build's revision.
I investigated and I believe this is due to a bug (or at least an inconsistency in the docs/typing) in svnkit (so I marked this as a PATCH not BUG for hudson) and I created a patch file as a workaround for my own use. I'm not sure how to attach it, in case anyone else has this problem...which I assume anyone on 32 bit systems using subversion+hudson has. It's just a matter of changing the call to SVNLogClient.doLog() to pass 0 instead of Long.MAX_VALUE.
I believe problem is a combination of svnkit not documenting (well enough) proper use of the limit parameter (which is a long) in SVNLogClient.doLog, and some int/long weirdness along the way to subversion itself. As it turns out, on 32bit systems the subversions max revision is 2^32-1, not 2^64-1 (Long.MAX_VALUE) ... so when svnkit passes this to subversion, I believe it's overflowing and only returning a single change to svnkit (and then to hudson). Passing 0 instead of Long.MAX_VALUE is consistent with the rest of svnkit's log limit requests, and results in it not adding a limit tag to its request to subversion (proper behavior). I may not be 100% correct on the explanation, but this definitely remedies a serious issue for me.
- environment:
Platform: All, OS: Windows XP
Activity
jenkins-infra-bot commentedon Sep 26, 2007
jmmckinnon:
Raw content of original comment:
Using Subversion 1.4.5 and running Hudson in Tomcat 5.5. Latest hudson means
1.143 and also HEAD
jenkins-infra-bot commentedon Sep 27, 2007
Raw content of original comment:
You can attach a file in thie issue tracker. Search for "Create a new
attachment". It might not be very obvious.
If you can't figure out how to attach a file, just send it to me.
jenkins-infra-bot commentedon Sep 27, 2007
jmmckinnon:
Raw content of original comment:
Created an attachment (id=94)
proposed patch
jenkins-infra-bot commentedon Sep 27, 2007
jmmckinnon:
Raw content of original comment:
Created an attachment (id=95)
proposed patch, unified. I think I screwed up the first file
jenkins-infra-bot commentedon Nov 14, 2007
dwdyer:
Raw content of original comment:
I've seen exactly the same problem in our live Hudson instance. Both
Subversion (1.3) and Hudson (1.146) are on 32-bit Windows 2003 Server machines.
On my home set-up (Subversion 1.4.2 on OS X, latest Hudson from CVS on Ubuntu),
I cannot reproduce the problem. Both of these machines are 32-bit also, so
perhaps the issue is more subtle?
Having looked at the SVNKit API, I think your proposed fix is sensible. I've
applied it and tested it and it introduces no problems so I have committed it
(version 1.10 of SubversionChangeLogBuilder.java). Should be in the 1.157
release.
jenkins-infra-bot commentedon Nov 29, 2007
Raw content of original comment:
jenkins-infra-bot commentedon Dec 12, 2025
[Original
is_duplicated_byfrom Jira: JENKINS-1020]