The fetch/load phase of the build does what's called a 'merge load', meaning it brings the load directory up to date with what's in the build workspace, only transferring what's needed. If you uncheck the delete-before-load setting in the build definition, it will usually only transfer what's changed.

This is a bit slower than only processing the files that are directly affected in the change sets since the last build, but is much more resilient, e.g. if a previous build failed partway through and only transferred some files, or someone deletes some or all of the load directory on disk, etc.

> why do you say 'usually'?
There are 3 basic cases:
1. initial build: everything gets transferred
2. subsequent builds (if everything worked as expected on the previous build): only the changed files get trasnferred
3. there was some corruption of the load dir previously, e.g. during the load, jbe was killed, or server went down, or random network errors occurred: it transfers whatever is needed to bring the load directory in sync with the build workspace

> how is this done?
it keeps metadata about the files on disc, including a hash of their contents. It compares the hash to the known hash server-side and only transfers if different.

> are the detected differences stored somewhere
No, the file deltas aren't stored. It's possible to list differences between builds though by comparing the snapshots associated with two builds, e.g. using the SCM command line tool. We're working on making this easier. See 59822: ANT task to generate text file with change set descriptions. This will list change sets, but have the option to list file deltas too.

Regards,
Nick