New files not showing up in agent work directory

SCM: Subversion
Runner: Maven 2
Agent: Default

I'm clearly missing something in terms of configuration because I'm really baffled at what is occasionally happening with our files.

Here's the scenario:

I commit code to subversion. TeamCity correctly identifies that a change has occurred and appears to get the new code from Subversion and it run the build successfully. The main page that lists the projects and build configurations shows the changed files. When I click one of the changed files and view it, I can confirm that it is correct and that the committed changes are indeed displayed.

All good right? Well no. If I go to the agent's work directory where (and I'm assuming here) the code was checked out to and built from, the actual file that I see there is wrong. It's the old version of the file. This is causing all kinds of problems because the build that was run actually generates jar files that are used in many places including our QA and test servers. Those people are expecting the new functionality that was checked in and that TeamCity told us was successfully built, however what they actually getting is old code. I don't even know how much older because I have no idea what logic TeamCity is using to report the supposedly successful build. What's worse is that it's inconsistent. Sometimes the build works just fine and all of the new code that is expected to be there is.

I'm stumped here. What am I doing wrong? I admit, I'm completely new to TeamCity. We just installed it yesterday after a year's worth of bad experiences with a competitor's product (rhymes with Ramboo). I'd be happy to post my settings. In fact I'll do so below. Any advice would be appreciated.

Matt W


General settings edit »
Name: Default Build
Description: none
Build number format: , next build number: #31
Clean all files before build: OFF
Maximum number of simultaneously running builds: 2
Fail build if at least one test failed: ON
Execution timeout: disabled
Status widget: disabled
Version control settings edit »
VCS checkout mode: Automatically on server
Checkout directory:
VCS labeling: disabled
Attached VCS roots:
Name Checkout rules Set label
Fusion SVN Root not specified NO
Runner: Maven2 edit »
Type of runner: Maven2 (Runner for Maven build file)
Artifact paths: none specified
Directory where pom.xml file is located: project/pom.xml
Goals: clean install
Additional Maven command line parameters: none specified
User settings path: /usr/local/fusion/maven/settings.xml
JDK home path: not specified
JVM command line parameters: not specified
Build triggering edit »
Build configuration is active (triggering enabled).
Trigger build by vcs check-in: ON
Start new build if last build is failed: OFF
Triggering by time: not configured
This configuration depends on: not configured
Artifact dependencies edit »
There are no artifact dependencies
Properties and environment variables edit »
System properties: none defined
Environment variables: none defined
Agent requirements edit »
Requirements for system properties: none defined
Requirements for environment variables: none defined

Comment actions Permalink


we also switched from the 'ramboo'-stuff to team-city ;) , are much more happier and went into production with TeamCity yesterday :-D.

We had the same issue you describe with CVS - see our JIRA-issue

Unfortunately at some point I wasn't able to reproduce the problem anymore - so we couldn't help jetbrains enough to find and fix the issue.

Currently we use the option 'Clean all files before build' in each of our builds - this takes a bit longer, but this is stable.

Comment actions Permalink

Hello Matthew,

what checkout mode do you use, checkout on agent or checkout on server?

Comment actions Permalink

Hello Matthew,

what checkout mode do you use, checkout on agent or
checkout on server?

I'm sorry it's taken me so long to respond.

We've tried both. We started with the default, which I believe was checkout on server, but then switched to the other. The settings I posted above show our original configuration. I thought that this had perhaps fixed the issue but I'm still getting reports from other developers that their commits aren't showing up. The commits do seem to trigger a build but the build doesn't include the new code. I'm not even sure how that can happen.

Perhaps I'll try Stefan's suggestion of the "clean all files" option although this is going to easily triple the time it takes to perform the build in our case. I'm not thrilled by that.

Message was edited by:
Matthew Welch

Comment actions Permalink

Perhaps I'm wrong about a commit triggering a build but the build not including the code. I'm almost certain that that was what was happening originally, but the report I got today indicated a different scenario: that a commit was made but no build was triggered. They made another arbitrary commit (just a whitespace change) in an attempt to prompt TeamCity to do a build and that second commit succeeded in triggering the build.

Is there anything I can look for, like log entires perhaps, that might help to diagnose the issue? It could very well be something on our side. Maybe the link between the build server and the source repo is having issues. Does the log record failed attempts to check the svn repository?

Comment actions Permalink

Ok, I think I stumbled on to what was occurring in our most recent troubles.The time on the build server was WAY off. Once it was corrected it started correctly picking up commits which triggered builds. This is not what was occurring with our original problem, but using "checkout on agent" instead of server seems to have helped there. So, for now at least, we seem to be running smoothly.

Comment actions Permalink

I had this happen a few times using Perforce. My quick fix was to delete the directory on the agent and force a new build. I could never figure out what happened. I'm pretty sure I did nothing out of the norm when it happened.

Comment actions Permalink

Hi Matt,
Any chance you can change the title to New files NOT instead of now. I assume that is what you meant. Not a big deal if you can't.


Comment actions Permalink


That's good you have found the issue with not synchronized time. We do have this requirement for Subversion and several other VCSes.

On the other hand, we would be very much interested in investigating the original problem you had. Even with the time differences there should be no situation when the changes are shown by the TeamCity but are not actually included into the build. This would be a major problem. If you ever encounter such behaviour please send us the server and agent logs, together with the relevant information on the changes displayed but not applied.

Best regards,

Yegor Yarko
Project Manager
JetBrains, Inc
"Develop with pleasure!"


Please sign in to leave a comment.