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

CVS plugin detect changes in 'rlog' but not in 'update'

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • cvs-plugin
    • None
    • CVS plugin 2.8

      So this is what I'm doing:

      I commit a file from GMT+1 timezone (CET), the CVS server and jenkins are running on GMT-7 timezone (PDT).

      After the commit, the Jenkins server detects my change, and it displays the commit log in the "changes" page, but the "cvs update" does not update to the latest revision.

      This is when using the "Use Update" version, if I uncheck this option, the plugin performs a checkout and it works correctly, it retrieves the latest revision.

          [JENKINS-17383] CVS plugin detect changes in 'rlog' but not in 'update'

          G P added a comment -

          I am using Jenkins 1.514 with CVS plugin 2.10
          CVS Server is 1.12.12
          CVS client is 1.12.13 (not sure this is relevant)

          I have a Maven project which checks its code out of CVS over an extssh connection. The following options are activate (checked):

          • Force clean copy for locally modified files
          • Prune Empty Directories

          If I check the option "Use Update", the build does not properly update the modified files (since last build was triggered).
          The change log properly displays the various commit message but the files are actually not updated on the disk.
          The cvs command that is executed are
          cvs update -C -d -P -r HEAD -D 23 Oct 2013 12:48:07 +0200 workspace
          cvs rlog -S -d06 May 2013 16:29:43 +0200<23 Oct 2013 12:48:07 +0200 xxxxxxxx

          If I uncheck the option "Use Update", the build updates properly the files on disk
          The CVS commands that are executed (or at least reported in the console log) are:
          cvs checkout -P -D 23 Oct 2013 13:05:09 +0200 -d workspace xxxxxxxx
          cvs rlog -S -d23 Oct 2013 13:04:13 +0200<23 Oct 2013 13:05:09 +0200 xxxxxxxx

          Only 2 files were updated since the last build and both were commited on May 24th 2013 so I don't think this is related to a date/time issue. I just checked the date and time on both server (CVS and Jenkins) and it seems to be correct on both.

          Mainly, this used to work before, so I am pretty sure this comes from the plugin (or one of its dependencies).

          If you need additional info, let me know.

          G P added a comment - I am using Jenkins 1.514 with CVS plugin 2.10 CVS Server is 1.12.12 CVS client is 1.12.13 (not sure this is relevant) I have a Maven project which checks its code out of CVS over an extssh connection. The following options are activate (checked): Force clean copy for locally modified files Prune Empty Directories If I check the option "Use Update", the build does not properly update the modified files (since last build was triggered). The change log properly displays the various commit message but the files are actually not updated on the disk. The cvs command that is executed are cvs update -C -d -P -r HEAD -D 23 Oct 2013 12:48:07 +0200 workspace cvs rlog -S -d06 May 2013 16:29:43 +0200<23 Oct 2013 12:48:07 +0200 xxxxxxxx If I uncheck the option "Use Update", the build updates properly the files on disk The CVS commands that are executed (or at least reported in the console log) are: cvs checkout -P -D 23 Oct 2013 13:05:09 +0200 -d workspace xxxxxxxx cvs rlog -S -d23 Oct 2013 13:04:13 +0200<23 Oct 2013 13:05:09 +0200 xxxxxxxx Only 2 files were updated since the last build and both were commited on May 24th 2013 so I don't think this is related to a date/time issue. I just checked the date and time on both server (CVS and Jenkins) and it seems to be correct on both. Mainly, this used to work before, so I am pretty sure this comes from the plugin (or one of its dependencies). If you need additional info, let me know.

          By 'used to work before', which version of the plugin was this with?

          Michael Clarke added a comment - By 'used to work before', which version of the plugin was this with?

          G P added a comment - - edited

          I just rolled back to version 2.7 and it works perfectly with that version, so the problem must come from a change between version 2.7 and 2.8. For me, this is actually a good workaround (use v 2.7) since the issues resolved after version 2.7 are not useful to me.
          Now, I noticed that the option "Force clean copy for locally modified files" did not exist in version 2.7. Could it be related to that?
          The command executed are:
          cvs update -d -P -r HEAD -D 23 Oct 2013 14:50:31 +0200 workspace
          cvs rlog -S -d23 Oct 2013 14:49:02 +0200<23 Oct 2013 14:50:31 +0200 Test
          I would suspect that this was introduced by this feature: https://issues.jenkins-ci.org/browse/JENKINS-15848. Could it be that by default the value of "Force clean copy for locally modified files" is "true" and that it would cause the problem? Previously there was an option "Perform clean checkout on failed update" which is checked on my CVS projects.
          I will try to use v2.10 but with the "Force clean..." set to false. I'll let you know the results.

          G P added a comment - - edited I just rolled back to version 2.7 and it works perfectly with that version, so the problem must come from a change between version 2.7 and 2.8. For me, this is actually a good workaround (use v 2.7) since the issues resolved after version 2.7 are not useful to me. Now, I noticed that the option "Force clean copy for locally modified files" did not exist in version 2.7. Could it be related to that? The command executed are: cvs update -d -P -r HEAD -D 23 Oct 2013 14:50:31 +0200 workspace cvs rlog -S -d23 Oct 2013 14:49:02 +0200<23 Oct 2013 14:50:31 +0200 Test I would suspect that this was introduced by this feature: https://issues.jenkins-ci.org/browse/JENKINS-15848 . Could it be that by default the value of "Force clean copy for locally modified files" is "true" and that it would cause the problem? Previously there was an option "Perform clean checkout on failed update" which is checked on my CVS projects. I will try to use v2.10 but with the "Force clean..." set to false. I'll let you know the results.

          Isaac Cruz added a comment -

          This issue only happens when using the "Force clean copy for locally modified files" (-C), which only makes sense when using update. So you can still use update if you unmark this option, that's what we are doing now.

          This bug started when the plugin switched from native 'cvs' to the cvsclient java library

          Isaac Cruz added a comment - This issue only happens when using the "Force clean copy for locally modified files" (-C), which only makes sense when using update. So you can still use update if you unmark this option, that's what we are doing now. This bug started when the plugin switched from native 'cvs' to the cvsclient java library

          G P - as Isaac mentioned - version 2.7 didn't have the 'Force clean copy' option which causes these issue - you can use version 2.10 and untick this option on any job that's causing issues.

          Michael Clarke added a comment - G P - as Isaac mentioned - version 2.7 didn't have the 'Force clean copy' option which causes these issue - you can use version 2.10 and untick this option on any job that's causing issues.

          G P added a comment -

          OK so I confirm what Isaac mentions: the "Force clean copy for locally modified files" is the cause of all issues. Unchecking that option makes the CVS plugin work properly. I just switched back to v2.10 and with that version it works properly. So we should probably close this issue and reopen issue JENKINS-15848 which does not work correctly for now.

          Michael, if you need more info or you want me to perform other tests, let me know.

          G P added a comment - OK so I confirm what Isaac mentions: the "Force clean copy for locally modified files" is the cause of all issues. Unchecking that option makes the CVS plugin work properly. I just switched back to v2.10 and with that version it works properly. So we should probably close this issue and reopen issue JENKINS-15848 which does not work correctly for now. Michael, if you need more info or you want me to perform other tests, let me know.

          Code changed in jenkins
          User: Michael Clarke
          Path:
          pom.xml
          http://jenkins-ci.org/commit/cvs-plugin/b3d0f6c51adddaa15032fe52c411415418098a29
          Log:
          [FIXED JENKINS-17383] Update to latest cvsclient

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Michael Clarke Path: pom.xml http://jenkins-ci.org/commit/cvs-plugin/b3d0f6c51adddaa15032fe52c411415418098a29 Log: [FIXED JENKINS-17383] Update to latest cvsclient

          Michael Clarke added a comment - Could one of you try the snapshot at https://jenkins.ci.cloudbees.com/job/plugins/job/cvs-plugin/202/org.jenkins-ci.plugins$cvs/artifact/org.jenkins-ci.plugins/cvs/2.11-SNAPSHOT/cvs-2.11-SNAPSHOT.hpi at let me know if this works for you?

          Sowrabha Chandrashekar added a comment - - edited

          CVS update command is not working with CVS plugin 2.8 and the below library.

          Below is the API, that I am calling for UpdateCommand :org.netbeans.lib.cvsclient.command.update.UpdateCommand

          <dependency>
          <groupId>org.jenkins-ci.lib</groupId>
          <artifactId>cvsclient</artifactId>
          <version>71-jenkins-11</version>
          </dependency>

          Sowrabha Chandrashekar added a comment - - edited CVS update command is not working with CVS plugin 2.8 and the below library. Below is the API, that I am calling for UpdateCommand :org.netbeans.lib.cvsclient.command.update.UpdateCommand <dependency> <groupId>org.jenkins-ci.lib</groupId> <artifactId>cvsclient</artifactId> <version>71-jenkins-11</version> </dependency>

          Re-closing issue. Latest comment was unrelated, duplicated in another issue, and does not provide enough information to allow the issue to be replicated.

          Michael Clarke added a comment - Re-closing issue. Latest comment was unrelated, duplicated in another issue, and does not provide enough information to allow the issue to be replicated.

            mc1arke Michael Clarke
            icruz Isaac Cruz
            Votes:
            9 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated:
              Resolved: