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

CVS updates not working correctly after upgrading CVS plugin from v1.6 to 2.8

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • cvs-plugin
    • Jenkins 1.510, CVS plugin 2.8, Linux RHEL 5

      I upgraded to CVS plugin version 2.8 from 1.6, and also ran the 'Manage Old Data' process from the Manage Jenkins screen.

      After the update, some projects were not retrieving changes that were committed to CVS and putting them into the workspace. If I clicked on the 'Recent Changes' link in Jenkins for the job, the changes would appear there, but they were not being pulled into the workspace and CVS polling log showed 'no changes'.

      For some projects this was not an issue, but for other projects it was. I checked the config files, and some had been updated to the 2.8 format and some still had the 1.6 format. The jobs that had been updated to the 2.8 format were the ones that were not pulling newly committed files into the workspace.

      It looks like the bug occurs when the config files use the 2.8 plugin format and the 'Use Update' option is selected (<canUseUpdate>true</canUseUpdate>). I deselected this option, and also selected 'Force clean copy for locally modified files' (<cleanOnFailedUpdate>true</cleanOnFailedUpdate>). The files then began to be correctly updated in the workspace.

      Here is a config file example where the 1.6 plugin format is used (and continues working with the 2.8 plugin installed):
      <scm class="hudson.scm.CVSSCM" plugin="cvs@1.6">
      <cvsroot>:pserver:user@server.com:/cvsroot/stuff</cvsroot>
      <module>ExModule</module>
      <canUseUpdate>true</canUseUpdate>
      <useHeadIfNotFound>false</useHeadIfNotFound>
      <flatten>false</flatten>
      <isTag>false</isTag>
      <excludedRegions></excludedRegions>
      </scm>

      And here is a config file example where the 2.8 plugin format is used and the files do not get updated when there is a commit to CVS:
      <scm class="hudson.scm.CVSSCM" plugin="cvs@2.8">
      <flatten>true</flatten>
      <repositories>
      <hudson.scm.CvsRepository>
      <cvsRoot>:pserver:user@server.com:/cvsroot/stuff</cvsRoot>
      <repositoryItems>
      <hudson.scm.CvsRepositoryItem>
      <modules>
      <hudson.scm.CvsModule>
      <localName></localName>
      <remoteName>ExJob2</remoteName>
      </hudson.scm.CvsModule>
      </modules>
      <location class="hudson.scm.CvsRepositoryLocation$HeadRepositoryLocation">
      <locationType>HEAD</locationType>
      <useHeadIfNotFound>false</useHeadIfNotFound>
      </location>
      </hudson.scm.CvsRepositoryItem>
      </repositoryItems>
      <compressionLevel>-1</compressionLevel>
      <excludedRegions>
      <hudson.scm.ExcludedRegion>
      <pattern></pattern>
      </hudson.scm.ExcludedRegion>
      </excludedRegions>
      <password>iLig231CAGwVtdt2/P6vseSiX+rCNjWwXG4/sAyjj1c=</password>
      <passwordRequired>true</passwordRequired>
      </hudson.scm.CvsRepository>
      </repositories>
      <canUseUpdate>true</canUseUpdate>
      <skipChangeLog>false</skipChangeLog>
      <pruneEmptyDirectories>true</pruneEmptyDirectories>
      <disableCvsQuiet>true</disableCvsQuiet>
      <cleanOnFailedUpdate>false</cleanOnFailedUpdate>
      <forceCleanCopy>true</forceCleanCopy>
      </scm>

      after changing to these values in the 2.8 plugin format:
      <canUseUpdate>false</canUseUpdate>
      <cleanOnFailedUpdate>true</cleanOnFailedUpdate>

      it appeared to start working again. I think it was because of the canUseUpdate flag.

            mc1arke Michael Clarke
            joel1234567 Joel Wheeler
            Votes:
            2 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: