We are struggling with frequent clean checkouts that take several hours do to our restricted perforce setup. I would like to get some advice if we can avoid clean checkouts or if there are any workarounds given our perforce restrictions.
After upgrading to teamcity 8.0.1 and adding a number of new configurations, personal builds regularly trigger a clean checkout because 'The project sources on the agent are newer than requested'. What happens is that config1 of a personal change is built at trunk revision N, followed by config2 of the same change (part of the same submission from the VS plugin) at trunk revision N-1.
Doing a clean checkout wouldn't be a big deal in many setups, but our repository is ~6GB and we are forced to use server side checkouts. This is because agent side checkouts hit the perforce 'maxscanrow' limit of our server (the limit of 'p4 sync ...@rev' corresponds to the number revisions of all files in the client spec). The limit could be avoided by syncing each line of the client spec individually.
Another issue is that teamcity doesn't cache the server side checkouts for some reason. Maybe caching server side checkouts would alleviate the above issues enough.
If someone could shed some light onto the following questions, that would be appreciated.
a) is there a way to prevent clean checkouts when syncing backwards? Is this a limitation of server side checkouts? We are using a single explicit client mapping for all configs.
b) how does teamcity determine which revision to test a personal change against, and why don't the revisions match across all configurations of a single personal run?
c) is there a simple pattern for replacing automatic checkouts with a manual script handling the p4 commands?
d) how can I debug why the server doesn't cache checkouts?
Thanks, and keep up the great work!