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

Speed up CVS changelog generation

XMLWordPrintable

    • Icon: Patch Patch
    • Resolution: Fixed
    • Icon: Critical Critical
    • core
    • 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.

            Unassigned Unassigned
            jglick Jesse Glick
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: