Intermittent issue where a cvs triggered build fails to update the static custom workspace properly. A commit went into CVS at Fri Apr 25 14:49:03 2014 UTC, the build was triggered at Apr 25, 2014 7:50:10 AM PDT (less than a minute later). The CVS update modified the CVS/Entries file with the new revision but left the old timestamp. The contents of the file remained the old version, but running manual cvs status claims the file is up-to-date and on the new revision. File is proven to be not updated and has the contents of the old revision. CVS can be corrected by adjusting CVS/Entries revision back to it's true value. Then when I manually update the file, the changes are incorporated and the CVS/Entries file is left correct.

This has occurred just twice in the last month or so, but make Jenkins unsuitable since it corrupts the workspace and reports invalid build breakages.

(redacted)

XXXXX/xxxxx > cvs status xxxxxx.h
===================================================================
File: xxxxxx.h Status: Up-to-date

Working revision: 1.132.2.1
Repository revision: 1.132.2.1 XXX/xxxxxx.h,v
Sticky Tag: BRANCH (branch: 1.132.2)
Sticky Date: (none)
Sticky Options: (none)

CVS status is apparently not checking the contents of the file.

Here we see the truth about the file
> grep \$Id xxxxxx.h

• $Id: xxxxxx.h,v 1.132 2013/11/26 20:23:34 sssssssss Exp $
  /

And other tests prove the local file is unchanged.

Below, a diff of CVS/Enties. The top one is from a fresh checkout of the branch and the bottom is our corrupt Jenkins workspace

< /xxxxxxx.h/1.132.2.1/Fri Apr 25 14:49:03 2014//TBRANCH
—
> /xxxxxxx.h/1.132.2.1/Tue Nov 26 20:23:34 2013//TBRANCH