TC 6.5.1 not detecting ClearCase checkins consistently

I am attempting to implement TeamCity on our new build server after using CruiseControl.NET for several years.  Since we are migrating from SVN to ClearCase (I am shaking my head, too), TC looked like it might be easier to configure for ClearCase than editing XML files.

Most of my msbuild scripts migrate over with little change, however I am not getting consistent results from the trigger.  Builds just aren't always triggered when there is a checkin.

Yesterday, there was a checkin of four files and a build was triggered.  Over night, there were 40 files checked in without a build being triggered.

If I add a file, a build gets triggered.  If I make a change to a file I have added, a build gets triggered.

Are there any thoughts on this?



Hi John

Technically TeamCity makes two separate actions

  1. The server continuously monitors VCS for changes, and displays new commits in UI like
  2. new builds are started by configured trigger rules

After performing commits, do you see registered pending chages in TeamCity?
Could you also post teamcity-server.log and teamcity-vcs.log, from a period of time when new changes were committed but a build didn't start.



I made a checkin to the root of the source this morning and that triggered a build.  However, a checkin about twenty minutes ago that was to file deeper in the tree did not.  I don't see the TC UI updated as you display.

The teamcity-server.log file around the time of my checkin has the following entries:

[2011-07-01 08:57:46,927]   INFO - ity.BuildQueuePriorityOrdering - New item QueuedBuildImpl{myBuildType=UCA 5.0 :: Debug {id=bt3},ItemId=116} with weight 0.00 inserted at the default position 0 in the end of the queue
[2011-07-01 08:57:46,935]   INFO - tbrains.buildServer.ACTIVITIES - Configuration added to queue; name=UCA 5.0 :: Debug {id=bt3}; requestor=ClearCase; promotion id=116
[2011-07-01 08:57:47,303]   INFO - tbrains.buildServer.ACTIVITIES - Build started; name=UCA 5.0 :: Debug, personal=false, buildId=114
[2011-07-01 08:57:47,307]   INFO - tbrains.buildServer.ACTIVITIES - Configuration removed from queue; name=UCA 5.0 :: Debug, requestor=ClearCase, comment=null, user=null, promotion id=116
[2011-07-01 08:57:47,316]   INFO -   jetbrains.buildServer.SERVER - Flush queue finished, number of builds started: 1
[2011-07-01 08:57:48,818]   INFO -   jetbrains.buildServer.SERVER - Running build saved to DB: UCA 5.0 :: Debug {id=bt3} # #51 {build id=114} on agent uc-build-2k8 triggered by ##vcsName='clearcase'
[2011-07-01 09:09:04,310]   INFO - de.impl.history.DBBuildHistory - Start creating history entry for UCA 5.0 :: Debug 114, date: 1309536544000
[2011-07-01 09:09:04,317]   INFO - de.impl.history.DBBuildHistory - End creating history entry for UCA 5.0 :: Debug 114
[2011-07-01 09:09:04,527]   INFO - tbrains.buildServer.ACTIVITIES - Finished 114

The teamcity-vcs.log file shows these entries around that time:

[2011-07-01 08:56:30,473]   INFO [1 {id=6} {id=6}] -      jetbrains.buildServer.VCS - Finish collecting changes for clearcase: C:\work\UCA_Client_5_0_devint\uca\uca_client {instance id=6, parent id=2} from version 01-July-2011.07:03:41 to version 01-July-2011.08:51:54; 1 changes collected 1 changes reported, time spent: 4m:35s,916ms
[2011-07-01 08:57:49,994]   INFO [rmal executor 4] -      jetbrains.buildServer.VCS - Requesting patch: root=clearcase: C:\work\UCA_Client_5_0_devint\uca\uca_client {instance id=6, parent id=2}, cleanPatch=false, prevVersion=01-July-2011.07:04:54, newVersion=01-July-2011.08:51:54, buildType=UCA 5.0 :: Debug {id=bt3}, buildId=114
[2011-07-01 09:01:56,647]   INFO [rmal executor 4] -      jetbrains.buildServer.VCS - Done requesting patch for root clearcase: C:\work\UCA_Client_5_0_devint\uca\uca_client {instance id=6, parent id=2} cleanPatch = false, prevVersion=01-July-2011.07:04:54, newVersion=01-July-2011.08:51:54, buildId = 114; took 246 sec 691 msec
[2011-07-01 09:01:59,230]   INFO [ttp-80-4 /RPC2 ] -      jetbrains.buildServer.VCS - Patch applied for agent=uc-build-2k8 {host=}, buildType=UCA 5.0 :: Debug {id=bt3}, root=clearcase: C:\work\UCA_Client_5_0_devint\uca\uca_client {instance id=6, parent id=2}, version=01-July-2011.08:51:54



Can you please enable debug logging and provide me full teamcity-clearcase.log file(s) if the issue occurs again?


Following the instructions detailed at the link you sent, I could not find the setting debug-vcs in the Administration UI, so I updated the teamcity-agent-log4j.xml as described.  For the teamcity-server-log4j.xml, there were only two elements related to ClearCase and neither were commented, one appender element and one category element.

After the update to teamcity-agent-log4j.xml, I deleted the contents of teamcity-clearcase.log and after restarting the server, I made a checkin of a changed file.  This checkin did not trigger a build and the teamcity-clearcase.log file remains empty.

Is there anything else I can do?



In Administration UI you should go to Server Configuration -> Diagnostics and choose "debug-ClearCase" logging preset.

And if you want to edit log configuration manually you need only "teamcity-server-log4j.xml" file to be changed:
1. Change "<priority value="INFO"/>" to "<priority value="DEBUG"/>" in ClearCase category.
2. Add "<param name="maxBackupIndex" value="20"/>" line to ClearCase appender.


Attached is the teamcity-clearcase.log file generated after updating the diagnostic settings as per your instructions.

At 8:04, I checked in changes to the file "C:\work\UCA_Client_5_0_devint\uca\uca_client\Client\CoreLibrary\NewHeights.PIM\Sources\OutlookEx\Tools.cs".  I see several instances of this file in the log, but it isn't clear why the build isn't being triggered.

On the other hand, a build was triggered yesterday when a checkin of changes to eight files was made.



According to the log, the directory "C:\work\UCA_Client_5_0_devint\uca\uca_client\Client\CoreLibrary\NewHeights.PIM\Sources\OutlookEx" has the following version tree:





C:\work\UCA_Client_5_0_devint\uca\uca_client\Client\CoreLibrary\NewHeights.PIM\Sources\OutlookEx@@\main\UCA_Client_int\1 (UCA_Client_5.0_import)

And according to your config spec, the version "\main\0" is used in your view. But this version of the directory has empty content, so the file "Tools.cs" was added in the branch "UCA_Client_int", but this branch is not visible in your view due to config spec.

So this change actually does not correspond to the specified view - that is why TeamCity does not detect it.

I can see the Tools.cs file in the view and the config spec is auto-generated by ClearCase.  Do you think this is a ClearCase configuration problem?


It is quite strange. What version of "C:\work\UCA_Client_5_0_devint\uca\uca_client\Client\CoreLibrary\NewHeights.PIM\Sources\OutlookEx" do you see in the view?


Config spec for the view you specified in TeamCity settings is:


element "[55497388efef11de8ae3001e6857dfbe=\uca]/uca_client/..." .../UCA_Client_5_0_devint/LATEST

element "[55497388efef11de8ae3001e6857dfbe=\uca]/uca_client/..." UCA_Client_5.0-20110617 -mkbranch UCA_Client_5_0_devint

element "[55497388efef11de8ae3001e6857dfbe=\uca]/uca_client/..." /main/0 -mkbranch UCA_Client_5_0_devint


And since "C:\work\UCA_Client_5_0_devint\uca\uca_client\Client\CoreLibrary\NewHeights.PIM\Sources\OutlookEx" has neither "UCA_Client_5_0_devint" branch nor "UCA_Client_5.0-20110617" label the version "/main/0" must be used. Are you sure you specified in TeamCity setting the same view you use in ClearCase Explorer?

Hi Maxim

I honestly don't know very much about ClearCase having been working with subversion for several years.  Our team exported our product code from subversion and handed it off to a ClearCase administrator at our company who then imported the code into a view named 'UCA_Client_int', then another view from that named 'UCA_Client_devint'.  The latter is the view that the team uses for development and the view that I am trying to make TeamCity work with.

After retrieving the code from ClearCase to the TeamCity server, what was the root of our code in subversion is now located at C:\work\UCA_Client_5_0_devint\uca\uca_client.  Since I have no history with ClearCase, I requested help with TeamCity configuration of the VCS root for our project.  He configured with C:\work\UCA_Client_5_0_devint as the "ClearCase view path" and uca\uca_client as the "Relative path within the view".  Currently, the Branches field is empty.  Clicking the Test Connection button is successful.

Files that are triggering build have version such as /main/UCA_Client_int/UCA_Client_5_0_devint/2 and are in folders that have similar versions all the way to the root.  This may be our workaround to this issue.  Unfortunately, that would mean a lot of benign updates just to get the folder versions in the correct format.

Thanks for your time and attention



John, out of curiosity, are you using ClearCase UCM or are you using base ClearCase? ClearCase UCM uses streams/projects and manages the config spec automatically.

We've had lots of trouble with TC not detecting checkins consistently.  I'm about to setup a prototype instance to debug this better and work with JetBrains to get the issue resolved.

What I found is that whenever a developer do a long delivery with lots of files (30-40?), it doesn't detect all of them.   My thread can be found at:


We are using UCM.

I found that if I add a file to a folder, then TC will trigger a build for any file that is in that folder.  I have written a script that traverses the folder tree, then in each folder (using ClearTool) checks in a new file, then removes it.  Unfortunately, our CC administrator doesn't want me to do this.  He is setting up Jenkins to see if he has better luck with that.  Personally, I would prefer to stay with TC as I like JetBrains products.  I have been using Resharper for a few years and I cannot work without it.

I will have a look at your thread.



In our environment, we have TeamCity monitoring the integration stream.  Developers have private streams and they deliver their changes to the integration stream.  The way ClearCase works when you deliver your changes, it checks the files out in the integration view.  Then the integration stream doesn't see the changes until you complete the delivery.  When you complete the delivery, it checks all of the files in at that time which can take some time if you have a lot of files and triggers are involved.

If I recall correctly, TeamCity uses "clt lshistory -since ...." to detect checkins. I think it runs the command periodically with a different timestamp.  The problem is that if your delivery takes 10 minutes, it doesn't detect all of the files because they have a check-in timestamp that is the same for all files.

Let's say that there are 200 files in your delivery and it takes 10 minutes to complete (rate of 20 checkins per minute).  You start completing the delivery at 1:00pm so that at 1:01pm, 20 files have been checked in, at 1:02 pm, 20 more files have been checked in, etc.

So TeamCity runs the command "clt lshistory -since 12:55pm ..." at 1:00pm, it will see that  somewhere between 0-20/40 files have changed (depends on how long lshistory takes to run).  Let's say that it runs again at 1:05pm with "clt lshistory -since 1:00pm", it will see that ~100 files have changed.  Then it runs again at 1:10pm with "clt lshistory -since 1:05pm". It'll see that zero files have chagned.  The other ~100 files won't get detected because it will have a checkin time of 1:00pm even though they were really checked in between 1:05-1:10pm.  That's the way ClearCase UCM deliveries work.

I did have several TeamCity instances running on different machines, monitoring the same stream. They would all detect different number of files depending on when they did the checking.


Please sign in to leave a comment.