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

Polling and Changelog do not pick up changes on CVS Tags

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Won't Fix
    • Component/s: cvs-plugin
    • Labels:
      None
    • Similar Issues:

      Description

      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.

        Attachments

          Activity

          Hide
          jonmr 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.

          Show
          jonmr 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.
          Hide
          mc1arke 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.

          Show
          mc1arke 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.
          Hide
          scm_issue_link 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.

          Show
          scm_issue_link 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 .
          Hide
          mc1arke 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

          Show
          mc1arke 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
          Hide
          mc1arke 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.

          Show
          mc1arke 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.

            People

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

              Dates

              • Created:
                Updated:
                Resolved: