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

Hg changelog calculation incorrect across slaves


    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Major Major
    • mercurial-plugin
    • None
    • Platform: All, OS: All

      Currently the Mercurial plugin's method of changelog calculation just involves
      pulling whatever it can into the workspace, and reporting what it pulled. If
      there are slaves involved and the job is not tied to a slave, this is wrong. E.g.

      (project init)
      (commit 0)
      (commit 1)
      (commit 2)
      #1 [slave-1] clone revs 0, 1, 2 -> empty changelog
      (commit 3)
      #2 [slave-2] clone revs 0, 1, 2, 3 -> empty changelog
      (commit 4)
      #3 [slave-1] pull revs 3, 4 -> changelog 3, 4
      (commit 5)
      #4 [slave-2] pull revs 4, 5 -> changelog 4, 5

      So many of the changesets will appear in the changelog for the same job multiple
      times (asymptotically once per slave).

      SubversionChangeLogBuilder uses a special file $build/revision.txt to track the
      last revision used by the job, so it only logs starting after that. MercurialSCM
      should do something similar. 'hg in' supports no --prune option, but 'hg log'
      does, so probably the solution is to pull first (can in fact dispense with the
      bundle file), then

      hg log --template ... --prune $tipOfPreviousBuild

      This would not be correct for a repo using local branches which might have been
      pulled. More precise would be:

      hg heads --template '


      \n' > revisions.txt
      hg log --template ... $(for n in $(cat revisions.txt); do echo --prune $n; done)

      Logging with --prune does seem to be slower on a big repo than 'hg in
      $aFewNewChangesets.hg' - very CPU intensive. On my laptop, logging with a prune
      of all but a handful of new changesets from the NB main repo using Hg 1.1.2
      takes almost two minutes of pure CPU. Probably this could be optimized in Hg if
      it were profiled and reported.

            jglick Jesse Glick
            jglick Jesse Glick
            2 Vote for this issue
            2 Start watching this issue