-
Patch
-
Resolution: Fixed
-
Critical
-
None
-
Platform: All, OS: All
For our builds, using a slow CVS server (operated by CollabNet) with a large
repository with many historical revisions, creating the CVS changelog is very
slow. In fact, it is slower than any other part of the build. Hudson calls cvs
log over the entire active portion of the repository, meaning many thousands of
files many of which have years worth of changes. This can take half an hour at
the minimum. It also adds a lot of load to the CVS server, making VC operations
slower for everyone.
The attached patch tries to solve this issue. It only runs log on those
CVS-controlled files in the working checkout which have a newer timestamp than
the previous build, on the assumption that any changes which have been updated
since then will have caused those files to be touched. This makes creation of
the CVS changelog much faster - and what time is spent on changelog calculation
is mostly in the Hudson server (scanning dirs for recently modified files)
rather than on the CVS server. That is to be preferred since CVS servers cannot
easily be replicated for load balancing. For our builds, the patch seems to
reduce typical build durations from about an hour to about 20 minutes.
The main drawback is that deleted files will not be noted in the changelog. This
is probably a reasonable tradeoff on the assumption that deletions are less
common than additions (in a project under development); much less common than
modifications; and less likely than either to cause a broken build or a major
functional change which would need to be noted in the changelog. I have looked
at ways in which this restriction could be removed without compromising
performance but so far have not found any good solution; see comments in patch
for details.
To be conservative, the code falls back to the current behavior in case it
cannot find any modified files.
This patch probably needs more field testing to see if it holds up in different
people's setups. It seems to be working for us.
You could argue that the patch should really be applied to Ant's <cvschangelog>
task, at least as an option.