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:

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.

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.

Null isn't accepted, you can provide an empty list of baselines if you only want to deliver change sets.
Cheers,
Jean-Michel