exporting changed files to the filesystem when building
4 answers
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.
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.
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.
Hi Nick,
I thought unchecking this checkbox would result in inconsistencies between load directory and the stream/repository workspace used for building. It seems to be smarter than that and it keeps everything in sync. Great! One question: why do you say 'usually'?
Thanks for the hint.
I'm now wondering 2 things...
1) how is this done; is RTC comparing the files while loading the directory? (timstamps, ...)
2) are the detected differences stored somewhere and do I have access to them when building
Regards,
Bernd van Oostrum.
> 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
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
> 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
Sounds great. I'm looking forward for the update. However... I'm wondering if this could also work when 'accept latest changes before loading' is NOT selected.
Regards,
Bernd.