new Jenkins team concert plugin performance issue: very long fetching files time
I'm evaluating new Jenkins Team Concert Plugin as it has better RTC integration. But I found the performance is terrible. As an example, it took 42m37s to fetching files in one of build (see screen shot below) even there is no changes. The old Jenkins plugin takes less than 1 min in updating sandbox!
One possible explanation is the new plugin using replace component to update build workspace, from the FAQ (https://jazz.net/wiki/bin/view/Main/BuildFAQ#How_should_my_source_code_be_loa), it says
When JBE updates the build workspace, it does so using a multi-component replace, not a regular accept, so discarded changes are properly removed, and there can be no conflicts. It also creates a snapshot after this to capture the state that will be built (except for personal builds). You can think of JBE as another developer that just brings his workspace up to date with what's in the stream (using replace, not accept). This provides the necessary isolation of the build from ongoing changes in the stream (the replace is done atomically).
Can anybody explain what is the difference between replace and accept? My understanding is that if a dedicated work space is used for continuous build and no changes will be made directly in that work space, there should be no much difference between accept and replace? Why the huge performance difference? Can anyone explain why it works in this way? and how to improve it.
|
Activity Label
|
Start Time
|
Activity Duration
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|