CruiseControl.net and Subversion

My project is not noticing when subversion gets updated. I have the exact same setup working on another server. This is a virtual server.

Here is my log file after I have made a commit. It seems like ccnet can see that there is an update but it just ends by saying no modifications detected.

2009-12-17 10:34:47,000 [MyProjectName Continuous Integration:INFO] Project: 'MyProjectName Continuous Integration' is first in queue: 'MyProjectName Continuous Integration' and shall start integration.
2009-12-17 10:34:47,000 [MyProjectName Continuous Integration:DEBUG] Checking if C:\Program Files\CruiseControl.NET\server\MyProjectName Continuous Integration\WorkingDirectory is a svn working folder
2009-12-17 10:34:47,000 [MyProjectName Continuous Integration:DEBUG] Starting process [svn] in working directory [C:\Program Files\CruiseControl.NET\server\MyProjectName Continuous Integration\WorkingDirectory] with arguments [log svn://myserver.com/trunk -r "{2009-12-16T21:19:48Z}:{2009-12-17T17:34:47Z}" --verbose --xml --username myusername --password mypassword --non-interactive --no-auth-cache]
2009-12-17 10:34:47,203 [444:DEBUG] [MyProjectName Continuous Integration svn] <?xml version="1.0"?>
2009-12-17 10:34:47,203 [444:DEBUG] [MyProjectName Continuous Integration svn] <log>
2009-12-17 10:34:47,203 [444:DEBUG] [MyProjectName Continuous Integration svn] <logentry
2009-12-17 10:34:47,203 [444:DEBUG] [MyProjectName Continuous Integration svn]    revision="1427">
2009-12-17 10:34:47,203 [444:DEBUG] [MyProjectName Continuous Integration svn] <author>myusername</author>
2009-12-17 10:34:47,203 [444:DEBUG] [MyProjectName Continuous Integration svn] <date>2009-12-16T18:34:50.148524Z</date>
2009-12-17 10:34:47,203 [444:DEBUG] [MyProjectName Continuous Integration svn] <paths>
2009-12-17 10:34:47,203 [444:DEBUG] [MyProjectName Continuous Integration svn] <path
2009-12-17 10:34:47,203 [444:DEBUG] [MyProjectName Continuous Integration svn]    kind=""
2009-12-17 10:34:47,203 [444:DEBUG] [MyProjectName Continuous Integration svn]    action="M">/trunk/MyProject/MyFile.cs</path>
2009-12-17 10:34:47,203 [444:DEBUG] [MyProjectName Continuous Integration svn] </paths>
2009-12-17 10:34:47,203 [444:DEBUG] [MyProjectName Continuous Integration svn] <msg></msg>
2009-12-17 10:34:47,203 [444:DEBUG] [MyProjectName Continuous Integration svn] </logentry>
2009-12-17 10:34:47,203 [444:DEBUG] [MyProjectName Conti开发者_如何学Gonuous Integration svn] </log>
2009-12-17 10:34:47,312 [MyProjectName Continuous Integration:INFO] No modifications detected.

I was able to fix this by updating to the latest ccnet. They use revisions instead of dates to update the trigger. after that it all just worked.

You don't have any modifications, you just think you do. This is a classic problem with Subversion that many CC.NET users fall prey to. Look more closely at the log and you'll see:

• The SVN command is being executed at 2009-12-17 10:34:47 (presumably you're in a GMT-7 timezone)
• The range of modifications being checked is from 2009-12-16 21:19:48 GMT to 2009-12-17 17:34:47 GMT - i.e., in the last 20 hours, more or less
• The only reported revision is from 2009-12-16 18:34:50.148524 GMT - BEFORE the start of the range.

In short, svn log lies, or at least fib a bit, in that it ALWAYS reports at least one change, even if it is older than the specified range. See SVN bug #1642 if you want the details. The odds are that it will never be fixed - the last comment is from 2004.

This is covered in the CC.NET doc:

CruiseControl.NET doesn't see my changes

The Subversion interface depends on the clocks of the CruiseControl.Net and Subversion servers being set within a small difference. Due to a long-standing Subversion bug (Bugzilla #1642) that appears unlikely to ever be fixed, CruiseControl.Net must filter the list of modifications returned by Subversion, looking for only those that fall within a specific time range. When the clocks of the two servers are significantly different, the filter may ignore modifications that should not be ignored. To prevent this problem, keep the clocks of the two servers set as closely together as possible.

Is your virtual server running with a future time?. Perhaps you should try some time synchronization.