Can you attach a job log showing the polling and update part of the CVS actions?

Yes, I've just created a new test job to keep it as short as possible.

So first, created a new module and a new job, and on first build everything went correctly.

Then I modify a file (src/main/scripts/testfile) and commit. This is the new content:
------------------
// CVS version control block - do not edit manually
// $Author: icruz $
// $Revision: 1.2 $
// $Date: 2013/03/27 14:44:48 $
// $Source: /mnt/cvs/finesse/testcvs/src/main/scripts/testfile,v $

This is a test

Modified!
------------------

Then I re-run the job, and this is the job output (I've set the "Use Update", "Prune Empty Directories", "Show all CVS output" and "Force clean copy for locally modified files" options):
------------------
Started by user anonymous
Building remotely on No DB node in workspace /opt/hudson/nodbnode/workspace/cvs-test
cvs update -C -d -P -r HEAD -D 27 Mar 2013 07:44:58 -0700 cvs-test
? cvs-test/target
cvs update: Updating cvs-test
cvs update: warning: cvs-test/pom.xml was lost
U cvs-test/pom.xml
cvs update: Updating cvs-test/src
cvs update: Updating cvs-test/src/main
cvs update: Updating cvs-test/src/main/scripts
cvs update: warning: cvs-test/src/main/scripts/testfile was lost
U cvs-test/src/main/scripts/testfile
cvs rlog -S -d27 Mar 2013 07:43:44 -0700<27 Mar 2013 07:44:58 -0700 finesse/testcvs
cvs rlog: Logging finesse/testcvs
cvs rlog: Logging finesse/testcvs/src
cvs rlog: Logging finesse/testcvs/src/main
cvs rlog: Logging finesse/testcvs/src/main/scripts
Parsing POMs
------------------

I don't know why that warnings appear when setting the "Show all CVS output", but anyway, I open the file in workspace and it's still on revision 1.1:
------------------
// CVS version control block - do not edit manually
// $Author: icruz $
// $Revision: 1.1 $
// $Date: 2013/03/27 14:43:23 $
// $Source: /mnt/cvs/finesse/testcvs/src/main/scripts/testfile,v $

This is a test
------------------
But in the "changes" page for this job run, my change is detected, here's a screenshot:
http://gyazo.com/fa4c9d7c6d2c01c17d366e74051fe54d

Thanks,
Isaac

What happens if you try and replicate these steps manually using a CVS client? The commands being passed by the CVS plugin seems valid, so the issue lies in either the CVSClient or the CVS server. I can change the CVS client if it is at fault, but the CVS server is outwith my control.

Ok, both the client and server are CVS 1.11.22.

$ cvs rlog -S -d"27 Mar 2013 07:43:44 -0700<27 Mar 2013 07:44:58 -0700" finesse/testcvs
cvs rlog: Logging finesse/testcvs
cvs rlog: Logging finesse/testcvs/src
cvs rlog: Logging finesse/testcvs/src/main
cvs rlog: Logging finesse/testcvs/src/main/scripts

RCS file: /mnt/cvs/finesse/testcvs/src/main/scripts/testfile,v
head: 1.2
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2; selected revisions: 1
description:
----------------------------
revision 1.2
date: 2013/03/27 14:44:48; author: icruz; state: Exp; lines: +6 -4
Test: modify file
=============================================================================

$ cvs update -C -d -P -D "27 Mar 2013 07:44:58 -0700"
cvs update: Updating .
cvs update: Updating src
cvs update: Updating src/main
cvs update: Updating src/main/scripts
U src/main/scripts/testfile

(and it updates the file to revision 1.2)

So both work correctly here... note that I have removed the "-r HEAD" option as this option together with -D was not working, it was removing all files saying that they were "no longer in repository"

Update: it seems to NOT be related to the date in -D option, I've changed the configuration to download a tag instead of HEAD (leaving the field empty so it actually use HEAD), and it still does not update to the last revision.

This is the command displayed in log:

cvs update -C -d -P -r HEAD cvs-test

It eventually downloads the last revision... but not at least after 1 hour

Update2: I have been testing the java CVS client, and discovered this issue is caused by the "-C" option.

If I execute this:
$ java org.netbeans.lib.cvsclient.commandLine.CVSCommand update -C -d -P
cvs update: Updating .
cvs update: warning: testfile was lost
U testfile

The testfile is NOT updated (in spite of the output).

If I execute this:
$ java org.netbeans.lib.cvsclient.commandLine.CVSCommand update -d -P
cvs update: Updating .
U testfile

The testfile is updated correctly

I confirm this issue - update not working.
(by the way: CVS client and server running in same timezone. CVS server = CVSNT server)

The update is seen in cvs logging, but the file is not updated.
I have the "force clean copy" (-C) option is check as well.

The workspace file is not updated. However, it did copy the "old" version to a ".#." file in the workspace (same directory as original file). But after that, the actual file is not updated to the latest (HEAD) version. So update is broken.

Could one of you who can replicate this issue try the attached snapshot. It uses the updated cvs client which contains changes for the CVS 1.12.13 protocol.

Seems it's still not working.

I have tried with the command line directly, using the new cvsclient-71-jenkins-9-SNAPSHOT.jar as CLASSPATH. And the same as before, if I use the "-C" option, the file is not updated:

$ java org.netbeans.lib.cvsclient.commandLine.CVSCommand update -C -d -P
cvs update: Updating .
cvs update: warning: testfile was lost
U testfile

But the testfile does not get updated to latest version (if I remove the -C then it does)

This happens to me too. This is actually a very severe issue because it means that we cannot rely on the update mechanism anymore. I am astonished that this issue does not get a greater priority (for me I consider this "Blocking").

This happens to me too, and for me its also a blocker because all jobs are configured to "Use Update" by default. If I uncheck "Use Update" or wipe out the workspace, checkout works.
Jenkins 1.516, CVS Plugin 2.9, CVS 1.11.22, RedHat 5.6

Has anyone narrowed down a possible cause for this? I'm unable to replicate it which means I have no way of identifying a fix.

Can someone who can replicate this issue re-enable update, but uncheck the 'Force Clean Copy for Locally Modified Files' option and see if they still get the issue?

When not using the "Force Clean Copy for Locally Modified Files" option, it works correctly.

This option makes update to fail, as I noticed in my latest comments... And it seems related to the cvsclient library, not to the plugin, because I made a test using directly this library

Code changed in jenkins
User: Michael Clarke
Path:
src/main/java/org/netbeans/lib/cvsclient/response/ModTimeResponse.java
http://jenkins-ci.org/commit/cvsclient/8432f1431829bb75ab305eec5b72da804e91272b
Log:
[FIXED JENKINS-17965 JENKINS-17383] parse timezone in server response

Compare: https://github.com/jenkinsci/cvsclient/compare/3003bc92180c...8432f1431829

Fixed in v2.10 of the plugin

Sorry but I just tested version 2.10 of the plugin and update still does not work. I switched back to "NOT use update" and my build was then correct.

G P: could you give some details about your environment and what you're seeing - I can't attempt to replicate your specific issue otherwise.

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.

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.

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.

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

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?

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.