I had the same problem. I got the "Workspace is inconsistent with configuration. Scheduling a new build: No CVS dir in ..." to go away by removing the spaces in the name of my Jenkins job.

So far this also seems to have cleared up the real problem where Jenkins sees a CVS change even when there wasn't one.

[EDIT]
BTW, I saw this prob on WinXP but I seem to recall issues with spaces in job names on Mac OS X and RHEL too.

HTH,
--johnt

well.. all my job names are already without space. I have used underscores , no spaces.

Vivek, I found another problem, and that seems to have been the real cause (for real this time!)

We had some directories in the CVS repository called XXX that only had an Attic (deleted files). There was a similar directory called Xxx (note the case difference) with the real files. Windows uses a case-insensitive files system, and that seems to have messed up CVS/Jenkins. The polling log showed that the files in XXX were no longer in CVS.

To fix the problem, I just went into the CVS repository and deleted the old XXX directory. PLEASE USE CAUTION when working directly on the repository! Unless you know exactly what you're doing, you can mess things up pretty seriously.

What happened to cause this mess?

A developer checked in XXX and the files in it, then decided he didn't like the name and moved the files to Xxx. In CVS, the directories still remain and there is no "rename" or "move", only add and delete. So we ended up with XXX (now empty) and Xxx with the correct files. Because Windows sees XXX and Xxx as the same thing, CVS checkout gets very confused.

That also explains why we never see this issue on RHEL or Mac OS X – both of those systems use a case-sensitive file system. (And before someone flames me, yes, I set up the Mac to use case-sensitive, and yes, I know it's case-INsensitive out the box.)

Good luck!
--johnt

the thing is all my stuff is on Linux. So case sensitivity is maintained. CVS and Jenkins are both installed on a Linux box..
Thanks for helping me out John

Vivek

All,
I have the same problem (since a long time ago) and I hope to add some details.

I have two identical jobs with some difference in the scm configuration:

• job A points to the HEAD of CVS repository
• job B points to the a specific brench of CVS repository:

Job A works fine, job B builds even without changes.

Both of them have the same CVS configuration and the same modules of the cvs specified.
Both of them have a 20 min polling trigger policy.
The only difference is HEAD/brench specification.

thanks for any ideas..
Francesco

Using 1.438 and seeing the same issue. This has suddenly started up again. Now sure what is going on. We don't have HEAD/branch differences. Everything is from HEAD and every project is doing this :S

I'm using 1.440 and seeing almost the same symptoms. The differences:

1) I'm using SVN instead of CVS.

2) Job doesn't start periodicaly, it starts only when there are chances in the source, but it always runs once with no changes before running with changes made. It's as if it knows there are changes but can not see them immediately.

3) My job source code has several modules that correspond to diferent directorys inside SVN repository

Heleno, your problem is a different one. On a quick view, I'd say that the clocks of your svn server and your Jenkins server are out of sync.
One way to fix this (and definitely a godd idea in any case) is to sync the clocks.
Another one is to append @HEAD to your subversion URLs.

Kutzi, you are right! It was the problem here. Since I have no control over the server's time sync, I used the @HEAD solution and it worked out just fine. Thanks very much.