cleartool lshistory returns non zero

TeamCity 5.0.3, Windows 2008 R2, Clearcase
Run build, Congiguration Problem found. Details are
Error collecting changes for VCS root  'Kms_2010.04_conman_VOB'
jetbrains.buildServer.vcs.VcsException: Process  cleartool lshistory -recurse -since 19-May-2010.08:27:20 -fmt  %u#--#%Nd#--#%En#--#%m#--#%Vn#--#%o#--#%e#--#%Nc#--#%[activity]p###----###\n  D:\TeamCity\SnapshotViews\KMS_2010_04\conman_VOB returns -1

Yet if I go on to the server and open powershell and run
PS D:\TeamCity\SnapshotViews\KMS_2010_04\conman_VOB> cleartool lshistory -recurse -since 19-May-2010.07:20:49 -fmt %u#--
#%Nd#--#%En#--#%m#--#%Vn#--#%o#--#%e#--#%Nc#--#%[activity]p###----###\n D:\TeamCity\SnapshotViews\KMS_2010_04\conman_VOB

PS D:\TeamCity\SnapshotViews\KMS_2010_04\conman_VOB> echo $lastexitcode
PS D:\TeamCity\SnapshotViews\KMS_2010_04\conman_VOB>

I get a zero. Anybody ideas what is going wrong here?
Regards, John


Just to add, after 3 hours and the system rerunning the command every 5 minutes, it suddenly worked. Made no changes to the project or clearcase.
be interested to know what is going on here.
And having added some new projects, am once again getting the -1 result from lshistory. If anyone has any idea on this I would be interested.
We are finding the teamcity/clearcase integration to be unreliable.



I noted you ran in the shell another command (it differs in "-since" key date). Can you please run exactly the first command and let me know whether it fails or not?


It does not fail. The view did not change during that time.
Also, cleartool tends not to give negative return values.
But we no longer get that command showing up, now I get
Error collecting changes for VCS root 'CupidRestate_2009.10_conman'
Checkout rule: +:.=>conman_VOB
jetbrains.buildServer.vcs.VcsException: Error executing lsvtree -obs -all D:\TeamCity\SnapshotViews\CupidRestate_2009.10\conman_VOB\.@@\main\0\Cupid2010_App\.@@\main\0\SOURCE: cleartool: Error: Pathname not found: "D:\TeamCity\SnapshotViews\CupidRestate_2009.10\conman_VOB\.@@\main\0\Cupid2010_App\.@@\main\0\SOURCE".

So, looking through the previous calls, I noticed the checkout rule was mentioned so I removed that to no avail

Error collecting changes for VCS root 'CupidRestate_2009.10_conman'
Checkout rule:
jetbrains.buildServer.vcs.VcsException: Error executing lsvtree -obs -all D:\TeamCity\SnapshotViews\CupidRestate_2009.10\conman_VOB\.@@\main\0\Cupid2010_App\.@@\main\0\SOURCE: cleartool: Error: Pathname not found: "D:\TeamCity\SnapshotViews\CupidRestate_2009.10\conman_VOB\.@@\main\0\Cupid2010_App\.@@\main\0\SOURCE".

The problem is (and other forum callers have mentioned this, is that eg Cupid2010_App\.@@\main\0\ will be empty and so there is no source.

Has team city been tested with this combination, certainly clearcase is very new to the W2008 R2 environment.


I'm getting a similar error. I can build nothing at the moment from clearcase. Any help or ideas would be appreciated.

[13:03:01]: Checking for changes

[13:19:43]: java.util.concurrent.ExecutionException: jetbrains.buildServer.vcs.VcsException: Problem collecting changes for 'Tibco :: D11 SCRE' : Error collecting changes for VCS root 'tibD11Scre'

jetbrains.buildServer.vcs.VcsException: Process cleartool lshistory -eventid -recurse -since 02-June-2010.13:03:01 -fmt %u#--#%Nd#--#%En#--#%m#--#%Vn#--#%o#--#%e#--#%Nc#--#%[activity]p###----###\n D:\Clearcase\tibD11Scre\PROD returns -1


I'm trying to run against a snapshot view. Since getting the above error, I've pared down the snapshot config spec so that it just points at one file deep in the source tree. I'm still getting no response from cleartool lshistory in the teamcity vcs and clearcase logs. It looks like teamcity is firing off multiple copies of cleartool for this also (I guess this is part of a re-try).

I tried running cleartool manually on the command line. For this view, if I report against the top level directory, it takes a very long time to come back. If I change -recurse to -all it is very quick. I'm not saying this is what should be done as I don't know if it gives the correct answer. Bottom line is, for the codebase I'm now looking at, with a large amount of elements (30k) and loads of branches and check ins, I can't use Teamcity for the build. This is even though I have the static view only containing a small subset of these elements (approximately 600 files).

I've burned the day on this and have officially given up.

Maybe teamcity can be modified to allow a longer timeout on the clearcase commands? At this point im not sure if this will help.



As a workaround you can select "Clean all files before build" option on the build configuration VCS settings page.


we always have that set. So that is not the workaround.


Sorry, this option can't remove usages of "lshistory" on collecting changes (it removes them only on building a patch), so it is really not a workaround.

Seems that in some cases "-all" key is better for "lshistory" command and in some other cases "-recurse" key is better. But in what cases exactly?

I created an issue: for investigating this problem.

So if you have any ideas on how to detect the key that should be used in each case, please write it there.

Now I plan to make a patch for making it available to choose this key manually via the TeamCity property.


Hi Maxim / John.
As per john, I also always have clean all files before build selected.

On -all / -recurse. I'm not sure.

My particular situation for the build I'm workin on now is that there is a very large amount of sources in the area of the vob I'm working on (the tibcoApplications one below.. I've had to chagne all the names etc):-

               huge tree below this folder containing 30000 elements

Even if I just make a config file pointing at one single file deep below the tibcoApplications folder, I'm still having the lsHistory problem when recurse is used. I think it is because recurse doesn't only recurse through everything in the view, it recurses through everything on the Clearcase server side.

For my .NET builds, I didn't have this problem, as the number of files and sources under consideration was relatively small. For this Tibco build I'm getting caught badly. I'm confused as this problem used not to happen before. It is about 6 months since I attempted such a build so I'm wondering is it that, the number of changes accumulated since have crossed some kind of threshhold, or is it that the clearcase plugin has changed in some way that breaks it in this situation.

I'm using the clearcase plugin that you recently created to resolve the version1's not being registered as changes. Would something have changed in it that could break this?

Best regards,


applied the new jar.
A build is now "checking for changes" forever. A build that takes 20 minutes tops is now going for 2.5 hours and still not moved from the first line of the build log.
I can change this to -recurse using the JVM start option you mention.Just to add that TC 5.1.2 does not have an file that I can find as mentioned in the docs.
But so far no success - before it fell over in a few minutes. Now it just builds but does nothing.
Not entirely sure why lshistory and lsvtree needs to be run - for a snapshot view, just a simple update -preview would tell if there are changes.Dynamic is harder.



Can you please just for investigation apply the patch I've attached to this post?

This patch can run "lshistory" command in six different modes. Each of these modes returns the correct result on my test server, but I want to know which variant works for you.

To set the mode you should set the value for "clearcase.lshistory.mode" property (one of "0", "1", "2", "3", "4", "5"), "0" is default value. Property "clearcase.use.lshistory.recurse" is ignored in this patch so you should not care about it.

Please let me know which modes work for you and which don't.


Please sign in to leave a comment.