perforce checkout issues

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!
Christian

1 comment
Comment actions Permalink

I have a partial answer for c): I ended up creating a meta-runner that splits the p4 sync into multiple commands (one per subdirectory). I then switched to manual checkouts into a specific folder, and added the p4 sync build step at the beginning of each configuration. However, this applies personal changes (of remote runs) before syncing, so I moved the sync step into a separate dependent configuration (I wish I could turn off applying personal changes in the sync config). Unfortunately, teamcity doesn't handle the case correctly where config B needs to run on agent X and depends on config A which can run on any agent (but is required to run on the same agent). It sometimes runs config A on agent Y, which prevents completing config B. So I ended up with multiple sync configs, creating a variant of A that needs to run on agent X as well.

0

Please sign in to leave a comment.