I just wanted to add a comment to say I'm experiencing this bug as well on my end. In our case we were using CVS 1.4 and the upgrade to 2.2 made this bug appear so we downgraded back to the 1.4 version.

It looks like we're not the only ones experiencing this - Michael can you reproduce the problem?

I am having the same exact problem with the projects that are dealing with a branch and not the HEAD.

I tried downgrading back to 1.6 and lost a whole bunch of my logs. It was only when I upgraded back to 2.2 (and 2.3 now) that my logs reappeared. So I don't really have the option of downgrading

The problem is still there in version 2.3

Desperately need fix...

Help...

Any developments on this front?

Sorry to assign this directly to you Kohsuke, but this ticket has been giving a few of us some serious issues and since it hasn't been assigned it's been ignored. Could you please get back to us on this one? Thank you so much.

I have the same problem, CVS Plugin 2.3 doesn't detect changes on a branch for me, but works on the HEAD, as previously mentioned. If there is any more information I can provide please let me know. Using 1.462 with the 2.3 CVS Plugin. My backup machine works fine using CVS Plugin 1.6 with the same settings.

I've created a change but can't prove it works without help from the people experienceing this issue.

Could some of you run:

cvs rlog -d"22 Mar 2012 09:26:21 -0400<27 Mar 2012 12:00:00 -0400" moduleName

changing the first timestamp to match the last succesful job start time, the second timestamp to match the time you're running the command and 'moduleName' to match the name of the module you're working with. Save the output into a text file along with the name of the branch/tag/head you're using. Feel free to obscure file/directory names but don't modify the overall structure of the document.

Executed command was: cvs rlog -d"02 May 2012 11:00:00 -0400<02 May 2012 15:30:00 -0400" portalInt
Current branch is d-chg00017366_op_brc_prod-op-2012-04-19
Module name is portalInt

Thank you for having a look.

Any luck Michael?

Yes and No. The modified plugin seems to pick up changes but then hangs after parsing some of them. I've not been able to narrow down what's causing this but I suspect it's a dodgy regular expression resulting in a field matching repeatedly and therefore going into a loop. I'll upload my changes as soon as I've fixed this issue so that you can try them.

Thanks Michael.

I think I've got a change that works, although your CVS rlog output isn't a useful test case given the branch you're using (it finds 0 changes). If I change to use your 'd-chg00017366_op_impl_2012-05-02_v20' branch then I find 8 changes from your rlog output which seems to be valid. I'll do a bit more testing then commit the changes to git.

Awesome!

Beautiful!

Code changed in jenkins
User: mc1arke
Path:
src/main/java/hudson/scm/CVSSCM.java
src/main/java/hudson/scm/CvsChangeLogHelper.java
src/test/java/hudson/scm/CvsChangeLogHelperTest.java
src/test/resources/hudson/scm/cvsRlogOutput_ISSUE-13227.txt
http://jenkins-ci.org/commit/cvs-plugin/8c0237ca871913bdaa53064e7be9979182ab1711
Log:
[FIX JENKINS-13227] Remove filters on CVS rlog and parse updated output

Code changed in jenkins
User: mc1arke
Path:
src/main/java/hudson/scm/CVSSCM.java
src/main/java/hudson/scm/CvsChangeLogHelper.java
src/test/java/hudson/scm/CvsChangeLogHelperTest.java
src/test/resources/hudson/scm/cvsRlogOutput_ISSUE-13227.txt
http://jenkins-ci.org/commit/cvs-plugin/1b2f7a4579f5de7a94d0eb5f846bc9ea724dfdac
Log:
Merge pull request #12 from mc1arke/JENKINS-13227

[FIX JENKINS-13227] Remove filters on CVS rlog and parse updated output

Compare: https://github.com/jenkinsci/cvs-plugin/compare/e3b432e...1b2f7a4

The changes have been committed to GIT and have succesfully built on ci.jenkins-ci.org (a problem on one of the remote slaves meant the build took 24 hours longer than normal). As my computer with my test jobs and dummy CVS repositories has died, could one of the people who can replicate this defect download the snapshot from http://ci.jenkins-ci.org/view/Plugins/job/plugins_cvs/31/org.jenkins-ci.plugins$cvs/artifact/org.jenkins-ci.plugins/cvs/2.4-SNAPSHOT/ (or perform a manual build from the GIT repository) and let me know if this works for them? I've been unable to test the change outside of unit testing so can't prove any failures or success.

I get a "504 Gateway Time-out" when I try the snapshot link.

Looks like the Jenkins CI server is struggling still. You should be able to download a snapshot from the Cloudbees server instead: https://buildhive.cloudbees.com/view/All/job/jenkinsci/job/cvs-plugin/org.jenkins-ci.plugins$cvs/

This is embarrassing...but where do these artifacts go in my /var/lib/jenkins?

You only need to download the hpi file and put it in the plugins folder in Jenkins home. If one does not already exist, you'll need to create an empty file called cvs.hpi.pinned then restart your Jenkins instance. If Jenkins is already running then you can goto the 'Advanced' tab in update centre and use the 'Upload Plugin' section to install the hpi file directly and therefore don't need to worry about incorrectly over-writing incorrect files.

The files that I have are cvs.jpi and cvs.jpi.pinned. Does it matter that the new files are .hpi?

Remove the cvs.jpi, rename the cvs.jpi.pinned to cvs.hpi.pinned and put the downloaded artifact in the plugins directory as cvs.hpi then restart jenkins

Here is what happens when I tried it on multiple slaves (Win and Linux):

• I commit a dummy change to the branch.
• Let the project kick off with an SCM poll, as well as I manually triggering it on another slave.
• Cleaned out the workspaces, so this is a clean checkout.
• The checkout by the Master goes fine.
• There is no 'computing changelog' stage.
• The matrix builds are initiated an in both instances I get:

16:00:58 hudson.util.IOException2: remote file operation failed: <workspace_location> at hudson.remoting.Channel@28509953:<slave_name>
16:00:58 at hudson.FilePath.act(FilePath.java:828)
16:00:58 at hudson.FilePath.act(FilePath.java:814)
16:00:58 at hudson.scm.CVSSCM.perform(CVSSCM.java:877)
16:00:58 at hudson.scm.CVSSCM.checkout(CVSSCM.java:808)
16:00:58 at hudson.model.AbstractProject.checkout(AbstractProject.java:1218)
16:00:58 at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586)
16:00:58 at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475)
16:00:58 at hudson.model.Run.run(Run.java:1434)
16:00:58 at hudson.matrix.MatrixRun.run(MatrixRun.java:146)
16:00:58 at hudson.model.ResourceController.execute(ResourceController.java:88)
16:00:58 at hudson.model.Executor.run(Executor.java:239)
16:00:58 Caused by: java.io.IOException: Unable to serialize hudson.FilePath$FileCallableWrapper@30f3caf4
16:00:58 at hudson.remoting.UserRequest.serialize(UserRequest.java:166)
16:00:58 at hudson.remoting.UserRequest.<init>(UserRequest.java:62)
16:00:58 at hudson.remoting.Channel.call(Channel.java:645)
16:00:58 at hudson.FilePath.act(FilePath.java:821)
16:00:58 ... 10 more
16:00:58 Caused by: java.io.NotSerializableException: hudson.scm.CvsRepositoryItem
16:00:58 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1180)
16:00:58 at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1362)
16:00:58 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1170)
16:00:58 at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528)
16:00:58 at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493)
16:00:58 at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
16:00:58 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
16:00:58 at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1362)
16:00:58 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1170)
16:00:58 at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528)
16:00:58 at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493)
16:00:58 at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
16:00:58 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
16:00:58 at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528)
16:00:58 at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493)
16:00:58 at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
16:00:58 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
16:00:58 at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528)
16:00:58 at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493)
16:00:58 at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
16:00:58 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
16:00:58 at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:346)
16:00:58 at hudson.remoting.UserRequest._serialize(UserRequest.java:155)
16:00:58 at hudson.remoting.UserRequest.serialize(UserRequest.java:164)
16:00:58 ... 13 more

After the failure, the build number says: No changes.

I have to correct. None of the above builds were triggered by an SCM change, they were all triggered manually.

Committed another dummy change. Wait for polling: No changes.

After I included the .hpi file and restarted Jenkins, it became cvs.jpi and cvs.hpi.pinned also became cvs.jpi.pinned but the latter file remained at size 0.

Looks like your stacktrace is being caused by another change introduced for this upcoming release. This will only affect jobs that use slaves as it's the sending of the items to the slave that's causing a problem. I'll apply a fix tonight and let you know when it's ready.

Would this prohibit the 'change detection' stuff? I have not been able to detect the changes on the branch with the new one.

I am building a Module that comes from a CVS branch.

'cvs checkout' correctly keeps the branch name in the Tag file.

Now after a clean checkout if the 'Use Update' is checked under 'Source Code Management' then the command looks like:

cvs update -d -P -r branch_name -D 15 May 2012 13:12:24 -0600 module_name

After this the Tag file will have 'D2012.05.15.19.12.24' in it which basically corresponds to the Head now.

This could be related to this.

Help please.

Amir - this sounds like a different problem (polling uses RLOG which doesn't care about the local tag file). Please raise a new issue for it.

I've committed a change to fix the serialization issue, could you see if this goes any way to resolving your main problem?

So 'cvs update' is out of the question. So here is what I did:

cvs checkout of the branch
build
commit a dummy change
wipe out workspace
cvs checkout of the branch
build

Changes page: No changes.

Then I committed another change
Let the SCM poll trigger (this is also a clean build without 'Use Update' checked)
No change.

Didn't work

Is there any way to revert back to what was there in say version 1.6?

I've installed the latest plugin and changes are still not picked up. I don't see anything suspicious in the logs. Is there something that could help you in our setup?

I was reviewing the CVS manual last night and it doesn't provide much insight. I can't find suitable free CVS hosting on the internet so I'm going to have to bite-the-bullet and try and setup a CVS server on my computer (my previous setup was lost when my primary computer died). Since I don't have access to your CVS server, could you confirm the setup (CVS Server version, authentication mechanism, how you connect etc) and also confirm that this issue only seems to happen on branches (polling seems to work on the head).

Thanks

I am getting the info on our CVS setup from the IT. In the meantime I can confirm that the projects that are polling the Head are fine, detecting changes and posting the changes on the web interface.

We're using CVSNT 2.5.03
We authenticate using pserver

I have been following this issue and I am also having similar problems .. in my case when I upgraded the plugin a lot of my builds started getting kicked off regularly like every hour .. and the version number are getting tagged every time a new build is kicked off which is supposed to happen only when new changes are found. so basically the builds are happening even when there are no changes and version tags are getting incremented.

This is the cvs polling log found in every build kicked every hour ..

Started on May 17, 2012 3:00:33 PM
cvs rlog: Logging lscpproxy-java
cvs rlog: Logging lscpproxy-java/bin
cvs rlog: Logging lscpproxy-java/build
cvs rlog: Logging lscpproxy-java/conf
cvs rlog: Logging lscpproxy-java/lib
cvs rlog: Logging lscpproxy-java/mib
cvs rlog: Logging lscpproxy-java/scripts
cvs rlog: Logging lscpproxy-java/src
cvs rlog: Logging lscpproxy-java/src/com
cvs rlog: Logging lscpproxy-java/src/com/n2bb
cvs rlog: Logging lscpproxy-java/src/com/n2bb/lscpproxy
cvs rlog: Logging lscpproxy-java/src/com/n2bb/lscpproxy/C1Udp
cvs rlog: Logging lscpproxy-java/src/com/n2bb/lscpproxy/db
cvs rlog: Logging lscpproxy-java/src/com/n2bb/lscpproxy/exceptions
cvs rlog: Logging lscpproxy-java/src/com/n2bb/lscpproxy/injection
cvs rlog: Logging lscpproxy-java/src/com/n2bb/lscpproxy/monitoring
cvs rlog: Logging lscpproxy-java/src/main
cvs rlog: Logging lscpproxy-java/src/main/xml
cvs rlog: Logging lscpproxy-java/test
cvs rlog: Logging lscpproxy-java/test/scripts
cvs rlog: Logging lscpproxy-java/test/src
cvs rlog: Logging lscpproxy-java/test/src/com
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb/lscpproxy
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb/lscpproxy/db
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb/lscpproxy/http
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb/lscpproxy/http/testServer
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb/lscpproxy/lsc
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb/lscpproxy/rtsp
Done. Took 0.32 sec
Changes found

I also get a lot of rlog errors like this :

java.lang.RuntimeException: Error while trying to run CVS rlog
at hudson.scm.CVSSCM.getRemoteLogForModule(CVSSCM.java:523)
at hudson.scm.CVSSCM.calculateRepositoryState(CVSSCM.java:459)
at hudson.scm.CVSSCM.compareRemoteRevisionWith(CVSSCM.java:320)
at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356)
at hudson.scm.SCM.poll(SCM.java:373)
at hudson.model.AbstractProject.poll(AbstractProject.java:1346)
at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:420)
at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:449)
at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

Can someone help ? I have tried to delte the projects and recreate them on jenkins and its not helping .. they are still getting triggered every hour ..

Client: Concurrent Versions System (CVSNT) 2.0.4 (client/server)
Server: Concurrent Versions System (CVS) 1.11.22-FCDQ_LEGO-2.2 (client/server)
Authenticating with pserver

(yes the server version appears to be customized but I've been guaranteed that the original sources were compiled and only the binary name has been changed)

I confirm that polling detects changes when run against the CVS head.

Thanks!

I tested it with the new plugin (2.4-SNAPSHOT (private-05/15/2012 16:22-hudson)). In The first project that was kicked off after polling for changes it went ahead and started checking out the entire cvs repository.

Here is sample cvs command ..
Started by an SCM change
Building on master in workspace /buildpool/jenkins/jobs/logClient-HEAD/workspace
cvs update -d -P -r HEAD -D 17 May 2012 17:22:54 -0400 workspace
cvs update: Updating ...

This happened while testing with a new project on Jenkins and also on a old project on Jenkins. Both of the project were pointing to HEAD.

Code changed in jenkins
User: mc1arke
Path:
src/main/java/hudson/scm/CVSSCM.java
src/main/java/hudson/scm/CvsChangeLogHelper.java
src/test/java/hudson/scm/CvsChangeLogHelperTest.java
http://jenkins-ci.org/commit/cvs-plugin/cd31307e33bc3749a71e5ad8d9f2a09cf3fd733d
Log:
[Fixed JENKINS-13227] change log and polling pick up branch changes properly
[Fixed JENKINS-13814] change log applies filers to prevent OOM Exceptions

Code changed in jenkins
User: mc1arke
Path:
src/test/resources/hudson/scm/cvsRlogOutput2.txt
http://jenkins-ci.org/commit/cvs-plugin/05e417c0c13367bda49761f9cab7618fdfba28ca
Log:
[Fixed JENKINS-13227] change log and polling pick up branch changes properly
[Fixed JENKINS-13814] change log applies filers to prevent OOM Exceptions

Latest snapshot should fix this issue - give it a shot and let me know.

Brilliant. It works. Thanks Michael.

I am only working with 'cvs checkout' since 'cvs update' overwrites the Tag file and screws everything up (issue 13789: this is a huge problem for us since our code is massive and a clean checkout and build from scratch every time kills the turn around times of these projects that deal with branches).

Can someone look at this please.

Amir: I'm going to fix the issue with losing settings when upgrading from the previous version to the current version then do a release. I'll look at your other issue after I've done the release as otherwise we'll never get this fix live.

Sounds like a plan.

Michael, I am getting this with this new snapshot. It is during the 'rlog' command.

First member of my matrix checks out and builds fine. Its rlog command is:

08:20:30 cvs rlog -S -d30 May 2012 17:13:58 -0600<31 May 2012 08:13:55 -0600 Module_name

The second member of the matrix, checking out the same exact code, rlog command is:

08:57:51 cvs rlog -S -d17 May 2012 09:30:15 -0600<31 May 2012 08:13:55 -0600 Module_name

Note the times! The second command fails with:

17:25:04 FATAL: No file version found for the specified tag. Looking for branch_name in
17:25:04 java.lang.RuntimeException: No file version found for the specified tag. Looking for branch_name in
17:25:04 at hudson.scm.CvsChangeLogHelper.getCurrentFileVersion(CvsChangeLogHelper.java:273)
17:25:04 at hudson.scm.CvsChangeLogHelper.mapCvsLog(CvsChangeLogHelper.java:151)
17:25:04 at hudson.scm.CVSSCM.calculateChangeLog(CVSSCM.java:419)
17:25:04 at hudson.scm.CVSSCM.checkout(CVSSCM.java:831)
17:25:04 at hudson.model.AbstractProject.checkout(AbstractProject.java:1218)
17:25:04 at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586)
17:25:04 at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475)
17:25:04 at hudson.model.Run.run(Run.java:1434)
17:25:04 at hudson.matrix.MatrixRun.run(MatrixRun.java:146)
17:25:04 at hudson.model.ResourceController.execute(ResourceController.java:88)
17:25:04 at hudson.model.Executor.run(Executor.java:239)

This is after the very last rlog message on the console output!!

On other slaves, I have this happening on the first member of the matrix or even on the master before triggering the first member of the matrix.

Sometimes when I clean the workspace and relaunch, it goes one step further, for example if it had failed on the master, now it passes and fails at the first member of the matrix on the slave!

I know why the exception is thrown and can resolve that. I don't understand the different timestamps but can take a guess (someone with more knowledge of matrix builds will have to confirm my ideas).

The CVS plugin does all commands with timestamps from the last completed (non-cancelled) job. Since matrix builds are really a set of different builds grouped under one run, different matrix configuration (I think it refers to them as axis) could potentially give different timestamps for a completed run. Can you look at your jobs and let me know if you can see any timestamps differing for last run start time (or end time) so I can either exclude this as an issue or try and investigate further.

I'll fix the exception in the meantime (some files could be changed in CVS and not be on the branch/tag we're looking at, when we set a filter on RLOG to only bring back a specific branch this was valid, but the assumption is now incorrect and likely to be broken).

Code changed in jenkins
User: mc1arke
Path:
src/main/java/hudson/scm/CvsChangeLogHelper.java
http://jenkins-ci.org/commit/cvs-plugin/cd691b3c0d97c04249a5f60db2d7a961f2d680eb
Log:
[FIXED JENKINS-13227] skip files not in current tag rather than throw exception

Michael,

I am using the snapshot from build 21. The 'Use Head If Not Found' seems to be broken. Even though it is checked, it tried to get that branch of the module which does not exist, therefore that module does not get checkout at all and I end up with an empty folder.

Amir: Your issue does not sounds like a polling or changelog failure so shouldn't be listed under this issue.

If you continue to have a problem then switch to the latest released version of the CVS plugin (currently 2.4) and try the failing action again. If it still doesn't work then check JIRA for any issues that sound the same and add the details of your failure to that issue, otherwise raise a new issue attaching your job config, console output and any other details that may be relevant to allow investigation.

Be aware that 'use head if not found' required the tag/branch you've asked for to at least exist in the repository - you can't just select a random tag name and expect it to switch to head on failing to find that tag.

Hi Michael,

Now, change detection is working with CVS Plugin 2.4

Thanks.

I am checking out multiple modules but only one of them has the branch I am specifying, the rest of them should come from the head. In version 2.3 the branch/head option could be specified per module but not in this snapshot, here I can only select 'Use Head If Not Found.' I will switch to 2.4 release and research this issue on JIRA.

Just came back from vacation, switched to the 2.4 release and everything works like a charm. Thank you so much Michael!