How to deliver change-sets programmatically?
Hi,
I need to deliver some change sets into a stream programmatically on the server side. How is it possible? I prefer do not deliver baselines, but only change sets.
I know the method IScmService.deliverCombined. It requires one baseline per component to make the bases of the corresponding components in the target workspace. However it is specified that "the lack of an entry for a given component indicates that the target workspace's basis for that component should remain unchanged". What does it mean? If I put a null value for a given component I obtain NullPointerException. How can I do not use baselines?
Thanks
Daniele
I need to deliver some change sets into a stream programmatically on the server side. How is it possible? I prefer do not deliver baselines, but only change sets.
I know the method IScmService.deliverCombined. It requires one baseline per component to make the bases of the corresponding components in the target workspace. However it is specified that "the lack of an entry for a given component indicates that the target workspace's basis for that component should remain unchanged". What does it mean? If I put a null value for a given component I obtain NullPointerException. How can I do not use baselines?
Thanks
Daniele
5 answers
Prior Art:
http://jazz.net/forums/viewtopic.php?t=8955
I'm evaluating the possibility of using the Java API to act as a bridge between our continuous integration server and a build workspace.
And I'm trying to make sure I understand the implications of NOT accepting baselines when I accept change sets.
Scenario - we create a dedicated build workspace which accepts changes from a developers repository workspace. Each time the CI-server polls for changes, we generate an IChangeHistorySyncReport. If new change sets are available, we scan the list of changes, removing any active changesets we find, and then accept the list into the build workspace, passing a Collections.EMPTY_LIST as the set of baselins.
We then create a new baseline for the build workspace, so that the ci-server can find its way back to this version of the source.
When I look at the build workspace in the Eclipse client, the Pending Changes view show that my Incoming Changes are now limited to the active change sets, and some baselines.
Is there any reason I should care about the baselines? It seems to me that I get no advantage from delivering baselines from the developer's workspace to the build workspace, nor is their advantage to going the other way.
http://jazz.net/forums/viewtopic.php?t=8955
I'm evaluating the possibility of using the Java API to act as a bridge between our continuous integration server and a build workspace.
And I'm trying to make sure I understand the implications of NOT accepting baselines when I accept change sets.
Scenario - we create a dedicated build workspace which accepts changes from a developers repository workspace. Each time the CI-server polls for changes, we generate an IChangeHistorySyncReport. If new change sets are available, we scan the list of changes, removing any active changesets we find, and then accept the list into the build workspace, passing a Collections.EMPTY_LIST as the set of baselins.
We then create a new baseline for the build workspace, so that the ci-server can find its way back to this version of the source.
When I look at the build workspace in the Eclipse client, the Pending Changes view show that my Incoming Changes are now limited to the active change sets, and some baselines.
Is there any reason I should care about the baselines? It seems to me that I get no advantage from delivering baselines from the developer's workspace to the build workspace, nor is their advantage to going the other way.
I agree that there are many situations where you do not want to deliver
baselines. There are several work items around this situation, most of
them referenced by work item 85458 "Baselines should be only delivered
by an explicit "promote" operation.". Please feel free to add your
comments/support to this (or the related work items). I personally am
in favor of 85458, since this would align the behavior of baselines with
the behavior of snapshots (which are just composite baselines).
Cheers,
Geoff
On 8/17/2010 3:07 PM, Danil wrote:
baselines. There are several work items around this situation, most of
them referenced by work item 85458 "Baselines should be only delivered
by an explicit "promote" operation.". Please feel free to add your
comments/support to this (or the related work items). I personally am
in favor of 85458, since this would align the behavior of baselines with
the behavior of snapshots (which are just composite baselines).
Cheers,
Geoff
On 8/17/2010 3:07 PM, Danil wrote:
Prior Art:
http://jazz.net/forums/viewtopic.php?t=8955
I'm evaluating the possibility of using the Java API to act as a
bridge between our continuous integration server and a build
workspace.
And I'm trying to make sure I understand the implications of NOT
accepting baselines when I accept change sets.
Scenario - we create a dedicated build workspace which accepts changes
from a developers repository workspace. Each time the CI-server polls
for changes, we generate an IChangeHistorySyncReport. If new change
sets are available, we scan the list of changes, removing any active
changesets we find, and then accept the list into the build
workspace, passing a Collections.EMPTY_LIST as the set of baselins.
We then create a new baseline for the build workspace, so that the
ci-server can find its way back to this version of the source.
When I look at the build workspace in the Eclipse client, the Pending
Changes view show that my Incoming Changes are now limited to the
active change sets, and some baselines.
Is there any reason I should care about the baselines? It seems to me
that I get no advantage from delivering baselines from the developer's
workspace to the build workspace, nor is their advantage to going the
other way.