Hi Wavellite,

the build repository workspace tied to the build definition is a regular repository workspace. If you uncheck the "delete directory before loading" and load the workspace into the directory on the server initially (by e.g. switching the build definition to "always build", then request build, then switch back to "build only if there are changes"), the workspace should remain loaded.
Now switch on "accept latest changes" in the build definition and only the latest changes from the stream to which the workspace is flowing will be accepted (and loaded) before each build.

However, build results and "private files" from previous builds will not be pruned from the load directory this way. Your build scripts would have to take care of deleting anything that the current build does not require.

For continuous incremental builds, this might be ok.
For release builds I suggest to use a cleanly loaded workspace.

- Arne

Why do you choose "delete the directory before loading", if you want to
only have the changes downloaded?

Cheers,
Geoff

On 8/11/2011 8:08 AM, wavellite wrote:

Via RTC , we always choose "delete directory before loading"
in build definition to order build condition. This means every time
the whole code should be download again in next time. But in most
case, only a few files are changed. To download the whole code will
waste much time, especially the RTC server is not at local. That is
not fit our strategy to reduce build time. So I want to know is there
any method in RTC to check out the appointed changes which can be
related to work items? Thanks!

Another approach to try:
As the first step of your build, save a copy of the source tree in a
temp location. Once your build has posted all the build results back to
RTC, have a final build step that deletes the source tree and moves the
temp location source tree back. This is basically a very reliable "make
clean". Now that you have a "clean" source tree, you can just have RTC
take care of a maximally efficient/accurate incremental source update on
your next build request (RTC will do an incremental update more
efficiently and accurately than your scripts would).

Note: I haven't tried this myself, so if someone does give it a try,
please let me know how it works for you.

I've submitted work item 174019 for an automatic "clean" operation
following a build, which I believe is what mostly motivates requests
like this.

Cheers,
Geoff

On 8/11/2011 11:38 PM, wavellite wrote:

gmclemmwrote:
Why do you choose "delete the directory before loading", if
you want to
only have the changes downloaded?

Cheers,
Geoff

On 8/11/2011 8:08 AM, wavellite wrote:
Via RTC , we always choose "delete directory before
loading"
in build definition to order build condition. This means every time
the whole code should be download again in next time. But in most
case, only a few files are changed. To download the whole code will
waste much time, especially the RTC server is not at local. That
is
not fit our strategy to reduce build time. So I want to know is
there
any method in RTC to check out the appointed changes which can be
related to work items? Thanks!

Yes, as Arne's said, our build are releases build.

So the reason why we choose "delete directory before
loading" is we want to get a clean build environment.

And for Arne's method, deleting "build results and private files
from previous builds" should exist unforeseeable risk and may
difficult to variable releases(e.g. some source code files are
updated in building, but no changes in repository).

In my opinion, I'd like that only the changes is loaded into a special
directory but still keep clean the previous build directory, then we
can combine the changes and the previous successful source code(we
can store them in a special place after build successful) together.
But in RTC, it looks like the change sets are fixed in the whole
source code when loading.