"Patch is broken" on initial clone of new project


I'm setting-up a new TC project for an old repo to bring this particular app into our CI process. However, the repo won't clone via TeamCity. The repo is large, it had some perf tracing logs accidentally checked-in once upon a time, but it does clone using msysgit for Windows we're all using. The Git repo's are on a Linux VM.

Any suggestions? Can I clone it myself and somehow move it into position in the agent's work folder? Can I configure TC to use the Git that's installed in the OS?


Luke (TC 7.1.4)

[14:24:19]Patch is broken, can be found in file: E:\TeamCity\buildAgent\temp\globalTmp\temp17657495653462715patch_838

[14:24:19]Failed to build patch for build # {build id=838}, VCS root: ssh://git@gitservername/~/ProductName.git#master {instance id=61, parent id=34}, due to error: Cannot find commit 84a588f66f458a59acac4124ffe71677bf7a06c2 in repository (E:\TeamCity-Configuration\system\caches\git\git-14E74081.git, ssh://git@gitservername/~/ProductName.git#master) jetbrains.buildServer.agent.impl.patch.PatchDownloaderImpl$1: Server was not able to build correct patch, most likely due to VCS errors at jetbrains.buildServer.agent.impl.patch.PatchDownloaderImpl.throwError(PatchDownloaderImpl.java:114)      at jetbrains.buildServer.agent.impl.patch.PatchDownloaderImpl.checkPatch(PatchDownloaderImpl.java:104)      at jetbrains.buildServer.agent.impl.patch.PatchDownloaderImpl.copyPatchAndCheck(PatchDownloaderImpl.java:65)      at jetbrains.buildServer.agent.impl.patch.UpdateSourcesPatcherBase.copyPatchToTempFile(UpdateSourcesPatcherBase.java:70)      at jetbrains.buildServer.agent.impl.patch.UpdateSourcesFromServer.updateSources(UpdateSourcesFromServer.java:62)


I've noticed in the \TeamCity\logs\teamcity-vcs.log some lines around this project's activity saying:

     There is not enough memory for git fetch, try to run fetch in a separate process.

These are my JVM arguments:

-Djava.util.logging.config.file=e:\TeamCity\bin\..\conf\logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Dteamcity.git.fetch.separate.process=false -Xrs -Xmx1024m -XX:MaxPermSize=512m -Dlog4j.configuration=file:../conf/teamcity-server-log4j.xml -Dteamcity_logs=../logs/ -Djava.endorsed.dirs=e:\TeamCity\bin\..\endorsed -Dcatalina.base=e:\TeamCity\bin\.. -Dcatalina.home=e:\TeamCity\bin\.. -Djava.io.tmpdir=e:\TeamCity\bin\..\tem

Note the memory settings.


Hi Luke,

First, I'd recommend to upgrae ot the latest TeamCity version (8.0.4 as of now) as it has lots of issues fixed, some of which are related to git support.

If still actual upon upgrade, you might need to collect the data anew and review Git integration internal properties.

As to your initial question, you can define no VCS roots in TeamCity and perform fetch and working copy update inside the build script. However, you will not get any changes displayed in TeamCity and will lose many of the related features, so 'd try to set up proper checkout first.


Thanks very much. Checking out as a build step is a great idea, so obvious now you mention it. Will use as last resort, thanks.


Just FYI, TeamCity 8.0 didn't resolve the issue.

     Cannot find revision d2601814e9f96afaf9159cb88ead833af433463e in VCS root 617.AuthorMapper.git.master

I'll have the repository reset bare and try again.

Then I'll see if I can work out how to get TC using a 64-bit JVM. May I suggest 64-bit by default?? I'm not really sure why 32-bit would be opted for, ever, in 2013.




> I'll have the repository reset bare and try again.

You can try to use clean checkout from build configuration Actions.

If this reproduces, please collect teamcity-vcs.log from the servr and agent covering the build triggering and running and attach them here or into the issue tracker/email.

> Then  I'll see if I can work out how to get TC using a 64-bit JVM.

JVM architecture is most probbaly unrelated to your issue, but here are notes on that for the agent.

> May I  suggest 64-bit by default?? I'm not really sure why 32-bit would be  opted for, ever, in 2013.

Bundling 64 bit JVM would mean 64 bit OS requirement for TeamCity, which is not always the case I am affraid. Also, there is little reason in running Agent under 64 bit as apart from larger memory consumption that brings almost nothing.


Thanks very much for the prompt response.

Just for background, this is a problem on Windows with a .NET application, although that's immaterial since the issue is before build. The problem could be that the repository is very large and consumes too much RAM, which is why I'm interested in the memory limitation imposed by 32-bit JVM.

I'm surprised at the 32-bit platform limitation, since I've not seen a 32-bit installation of Windows since 2003, ten years ago! Even my wife's mobile phone is 64-bit. And simply running in a 64-bit JVM won't increase memory usage.

Anyway, I'm not here to argue, its a great product and you're a good team, I just find it curious that's all.




Just a note: In my previous comment I referred to agent, but you are using server-sider checkout, so only logs from the server would be useful.
If you can get teamcity-vcs.log covering the error, that would be great!


Can you do me a huge favour and just give me a hint about what I do to get TC using a 64-bit JRE. I've read the documentation but I know nothing about Java.

Do I install 64-bit JRE onto my Windows box and the copy the binaries from its install location to the TC /jre folder? Is that it? People I ask keep saying that I must 'point' the app at the JRE, but your documentation reads like I have to copy some files around.

I can't buy you a beer but there's some stack-rep points on offer here:


Stuck. Thanks.



I've answered at StackOverflow. Please note that after switching to x64 JDK generally you will need to increase the memory-realted paramters of JVM more then twofold to get any actual memory increse.

The corresponding section in the doc with the linked sections should provide you with the informatino you need.


So I should update the thread. We have TC running on 64-bit JRE though I haven't yet changed the memory settings. I did reset the Git repo to bare and push master to it, but now I have a different problem:

   Cannot find revision of the default branch 'master'

Is in the project build log on the web portal. In the teamcity-vcs.log there is this:

[2013-11-21 11:46:11,791]   WARN [l executor 3452] - ggers.vcs.git.FetchCommandImpl - There is not enough memory for git fetch, try to run fetch in a separate process.

[2013-11-21 11:46:11,823]   WARN [l executor 3452] -      jetbrains.buildServer.VCS - Unable to collect changes for [ProductName :: ProductName Website - Build QA packages and run tests {id=bt31, internal id=bt31}]: Error collecting changes for VCS repository '"617.ProductName.git.master" {instance id=61, parent internal id=34, parent id=617_ProductName_git_master, description: "ssh://git@git-svr0617/~/ProductName.git#master"}'

Cannot find revision b8367f3fbbfd4cd95877b788d11716deac740f73 in VCS root 617.ProductName.git.master {id=61}

So I'll up the memory. I don't understand why the build log has a different error, I don't know which to believe.



Pulling the thread indentation back.

So now I have -Xmx2048m -XX:MaxPermSize=270m and it gives me a proper memory exception in the UI, web portal:

Failed to collect changes, error: Error collecting changes for VCS repository '"617.ProductName.git.master" {instance id=61, parent internal id=34, parent id=617_ProductName_git_master, description: "ssh://git@svr0617/~/ProductName.git#master"}'

'git fetch' command failed.

stderr: java.lang.OutOfMemoryError: Java heap space

 at org.eclipse.jgit.storage.pack.BinaryDelta.apply(BinaryDelta.java:163)

 at org.eclipse.jgit.storage.pack.BinaryDelta.apply(BinaryDelta.java:118)

 at org.eclipse.jgit.transport.PackParser.resolveDeltas(PackParser.java:594)

 at org.eclipse.jgit.transport.PackParser.resolveDeltas(PackParser.java:571)

 at org.eclipse.jgit.transport.PackParser.resolveDeltas(PackParser.java:534)

 at org.eclipse.jgit.transport.PackParser.parse(PackParser.java:491)

 at org.eclipse.jgit.storage.file.ObjectDirectoryPackParser.parse(ObjectDirectoryPackParser.java:179)

 at org.eclipse.jgit.transport.PackParser.parse(PackParser.java:433)

 at org.eclipse.jgit.transport.BasePackFetchConnection.receivePack(BasePackFe...

Also set is:


So I'll make that false and up the RAM to 4g.


Please sign in to leave a comment.