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

Polling and Changelog do not pick up changes on CVS Tags

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Major Major
    • cvs-plugin
    • None

      When creating a job using a cvs branch, and cvs plugin does the checkout and rlog, but finds nothing. Using the same parameters from the commandline, using linux cvs client, it does see the changes.

      From the log:
      cvs rlog -S -d07 Aug 2012 17:47:11 +0300<07 Aug 2012 18:12:20 +0300 base-iso
      cvs rlog: Logging base-iso
      cvs rlog: Logging base-iso/.disk
      cvs rlog: Logging base-iso/boot

      but from the commandline:
      cvs rlog -S -d"07 Aug 2012 17:47:11 +0300<07 Aug 2012 18:12:20 +0300" base-iso
      cvs rlog: Logging base-iso

      RCS file: /opt/cvsroot/base-iso/create_iso.sh,v
      head: 1.6
      branch:
      locks: strict
      access list:
      symbolic names:
      keyword substitution: kv
      total revisions: 6; selected revisions: 1
      description:
      ----------------------------
      revision 1.6
      date: 2012/08/07 14:47:55; author: urim; state: Exp; lines: +1 -1
      Changelog
      =============================================================================
      cvs rlog: Logging base-iso/.disk
      cvs rlog: Logging base-iso/boot
      cvs rlog: Logging base-iso/boot/grub

      After downgrading to CVS plugin 1.6, the changes list is working, so it seems to be a problem with the cvs library.

          [JENKINS-14711] Polling and Changelog do not pick up changes on CVS Tags

          Reducing priority given there is a workaround (tick the 'Show all CVS Output' box) and that this does not seem to be impacting a lot of users

          Michael Clarke added a comment - Reducing priority given there is a workaround (tick the 'Show all CVS Output' box) and that this does not seem to be impacting a lot of users

          Jon Radon added a comment - - edited

          There's a workaround, but it doesn't appear to work in the latest version. Adding my vote for this.

          Jon Radon added a comment - - edited There's a workaround, but it doesn't appear to work in the latest version. Adding my vote for this.

          Anders Monrad added a comment -

          Using version 2.7 we see the same issue, no matter if Show all CVS Output is checked or not. We also often see an exception (JENKINS-16044)

          Anders Monrad added a comment - Using version 2.7 we see the same issue, no matter if Show all CVS Output is checked or not. We also often see an exception ( JENKINS-16044 )

          Jon Radon added a comment -

          Still appears to be happening in 2.8. "Show all CVS Output" has no effect.

          Jon Radon added a comment - Still appears to be happening in 2.8. "Show all CVS Output" has no effect.

          Jon: can you confirm what you're not seeing a changelist for; is your module on HEAD, BRANCH or TAG?

          Michael Clarke added a comment - Jon: can you confirm what you're not seeing a changelist for; is your module on HEAD, BRANCH or TAG?

          Jon Radon added a comment -

          Michael: My module is on a TAG. The project polls hourly for changes on a tag named RTB_13_4. I can probably provide a config or log if needed. I also looked at the code a little, but wasn't sure where to start.

          Jon Radon added a comment - Michael: My module is on a TAG. The project polls hourly for changes on a tag named RTB_13_4. I can probably provide a config or log if needed. I also looked at the code a little, but wasn't sure where to start.

          Searching for changes on a tag in a multi-module setup is not as easy at it sounds. Consider the following:
          1. A user checks in changes on a branch/head (we may or may not be monitoring this location, it doesn't really matter). At the same time they check in changes on a branch/head we are monitoring.
          2. Polling picks up these changes and a build is scheduled
          3. The build completes so the last checked timestamp is rolled forward to the build's start time.
          4. The user changes the existing tag to point to a new version of the file. Since tagging doesn't create any commit messages and the commit messages for the changed files have already been seen in the last build, no message appears in rlog for the files changed in the tag. Polling therefore doesn't see a change so doesn't schedule a build.

          It would be possible to pick-up changes on a tag if the changes and re-tag happen in the same polling cycle, but there's no way to guarantee this especially if polling is scheduled to happen frequently. I can apply such a change before the next release, although this could result in users who change tag contents seeing inconsistent polling behaviour depending on how their commits compare to the polling cycle.

          To try and pick-up all situations where a tag would change, polling would have to be done using the full repository history - not just changes between the last build and current poll. This isn't particularly practical as frequently changed repositories are going to have a large change-log so require a lot of time, memory and processing cycles to retrieve and parse.

          Michael Clarke added a comment - Searching for changes on a tag in a multi-module setup is not as easy at it sounds. Consider the following: 1. A user checks in changes on a branch/head (we may or may not be monitoring this location, it doesn't really matter). At the same time they check in changes on a branch/head we are monitoring. 2. Polling picks up these changes and a build is scheduled 3. The build completes so the last checked timestamp is rolled forward to the build's start time. 4. The user changes the existing tag to point to a new version of the file. Since tagging doesn't create any commit messages and the commit messages for the changed files have already been seen in the last build, no message appears in rlog for the files changed in the tag. Polling therefore doesn't see a change so doesn't schedule a build. It would be possible to pick-up changes on a tag if the changes and re-tag happen in the same polling cycle, but there's no way to guarantee this especially if polling is scheduled to happen frequently. I can apply such a change before the next release, although this could result in users who change tag contents seeing inconsistent polling behaviour depending on how their commits compare to the polling cycle. To try and pick-up all situations where a tag would change, polling would have to be done using the full repository history - not just changes between the last build and current poll. This isn't particularly practical as frequently changed repositories are going to have a large change-log so require a lot of time, memory and processing cycles to retrieve and parse.

          Code changed in jenkins
          User: Michael Clarke
          Path:
          src/main/java/hudson/scm/CvsLog.java
          src/test/java/hudson/scm/CvsChangeLogHelperTest.java
          src/test/java/hudson/scm/CvsLogTest.java
          http://jenkins-ci.org/commit/cvs-plugin/1900841791d1fbafc1839f0adea99452718f65a8
          Log:
          JENKINS-14711 Pick up changes on a tag since last polling cycle


          You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com.
          For more options, visit https://groups.google.com/groups/opt_out.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Michael Clarke Path: src/main/java/hudson/scm/CvsLog.java src/test/java/hudson/scm/CvsChangeLogHelperTest.java src/test/java/hudson/scm/CvsLogTest.java http://jenkins-ci.org/commit/cvs-plugin/1900841791d1fbafc1839f0adea99452718f65a8 Log: JENKINS-14711 Pick up changes on a tag since last polling cycle – You received this message because you are subscribed to the Google Groups "Jenkins Commits" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out .

          Snapshot build of changes at https://buildhive.cloudbees.com/job/jenkinsci/job/cvs-plugin/80/org.jenkins-ci.plugins$cvs/artifact/org.jenkins-ci.plugins/cvs/2.9-SNAPSHOT/cvs-2.9-SNAPSHOT.hpi

          These changes are not currently on head so will not be on the next release until I've had more of a think about this and someone has convinced me that we should poll for tag changes

          Michael Clarke added a comment - Snapshot build of changes at https://buildhive.cloudbees.com/job/jenkinsci/job/cvs-plugin/80/org.jenkins-ci.plugins$cvs/artifact/org.jenkins-ci.plugins/cvs/2.9-SNAPSHOT/cvs-2.9-SNAPSHOT.hpi These changes are not currently on head so will not be on the next release until I've had more of a think about this and someone has convinced me that we should poll for tag changes

          Given my previous comment about the risks in trying to pick changes in a tag, I have decided that this issue will not be fixed. Moving a tag is regarded as bad practice and trying to introduce a method of finding these changes would significantly increase CPU and Memory usage of the CVS plugin which such a fix doesn't warrant.

          Michael Clarke added a comment - Given my previous comment about the risks in trying to pick changes in a tag, I have decided that this issue will not be fixed. Moving a tag is regarded as bad practice and trying to introduce a method of finding these changes would significantly increase CPU and Memory usage of the CVS plugin which such a fix doesn't warrant.

            mc1arke Michael Clarke
            milman uri milman
            Votes:
            3 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved: