Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

is there anyway only check out the appointed changes?

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!

0 votes



4 answers

Permanent link
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

0 votes


Permanent link
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!

0 votes


Permanent link
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.

0 votes


Permanent link
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.

0 votes

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details

Question asked: Aug 11 '11, 5:01 a.m.

Question was seen: 5,623 times

Last updated: Aug 11 '11, 5:01 a.m.

Confirmation Cancel Confirm