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.