Delivery would cause a conflict.

Hi,

I'm trying to implement recipe #2 in http://jazz.net/library/article/195 for a example project I have created to test the correctness of this approach for a future project I will be working on.
I have the requirement:
As a build engineer, I want to build from Component HelloWorld and copy the build artefact (the "hello" app) into a second component Dist. I then want to deliver the resulting changeset into a second stream called HelloWorld Release to be used in producing the StarName app.

To meet this goal
I have created 3 components: Dist, HelloWorld, and StarName.
I have created 2 streams
HelloWorld contains components Dist and HelloWorld
HelloWorld contains components Dist and StarName
I have created two Repositories:
HelloWorld Build which Flows to HelloWorld Stream
HelloWorld Release Build which Flows to HelloWorld Release Stream

I have tried to duplicate recipe 2 in Bash instead of Ant.
The build worked one time and did deliver the "hello" app into HelloWorld Release Stream, however, since any build from HelloWorld Build respository now errors out with code 11 and produces a rather useless message (at least to me):
Problem running 'deliver':
Delivery would cause a conflict.

My build script:

workspace=$(grep "team.scm.workspaceUUID" ../build.properties |cut -d '=' -f 2)
target=$(grep "Target" ../build.properties |cut -d '=' -f 2)
args="--non-interactive -a n -u y"
#build project
make
mkdir -p ../ship
cp hello ../ship
cd ..
echo "Checking in build artifacts"
foo=$(/opt/ibm/jazz/scmtools/eclipse/scm $args checkin ship/hello)
echo -e $foo
echo "Get Changeset UUID"
regex='.*\((.*)\).*'
uuid=$(echo -e `expr match "$foo" $regex` | sed -e 's/(//' -e 's/)//')
echo "Changeset UUID = $uuid"
echo "Delivering to changeset $uuid to stream $target"
/opt/ibm/jazz/scmtools/eclipse/scm --non-interactive deliver -v -t $target $uuid


Output
Checking in build artefacts
Committing... Workspace: (_AnwQ4NurEd-9Jpi2ePnVVQ) "HelloWorld Project Workspace" <-> (_yuto4NhGEd-9Jpi2ePnVVQ) "HelloWorld Project" Component: (_ZgdtUNufEd-9Jpi2ePnVVQ) "Dist" Outgoing: Change sets: (_le7HsdyBEd-9Jpi2ePnVVQ) --@ <No>
Changeset UUID = _le7HsdyBEd-9Jpi2ePnVVQ
Delivering to changeset _le7HsdyBEd-9Jpi2ePnVVQ to stream _1BibsNuqEd-9Jpi2ePnVVQ
Delivering changes from "HelloWorld Project Workspace" into "HelloWorld Release 1.0"
No baselines to flow.
Problem running 'deliver':
Delivery would cause a conflict.
Build failed. Exit value was 11.

Anyone have any guidance on what "Delivery would cause a conflict" might be trying to tell me?

The error means that if the changes in the change set is delivered to the "HelloWorld Project" stream it will cause a conflict in the target stream because there are newer changes (for Dist component) in the target stream.

The current workspace has to resolve those conflicts before delivering it to the stream. To resolve the conflicts, you have to change the flow target of the component to the target stream, accept any incoming changes, resolve the conflicts and then deliver the changes. While resolving if you want to keep your version of the change, you can run "scm resolve --checkedin" to retain your change.


I assume you meant "HelloWorld Release 1.0" and Not "HelloWorld Project". My build is checking into a different stream. Assuming your post contained the mistake noted, it implies that I must perform and action that I'm trying to avoid, namely, performing a load operation on the HelloWorld Release 1.0 workspace just to check in a single change set. The example in recipe 2 of http://jazz.net/library/article/195 does not show any load or resolve action prior to checking the change to the other stream. In addition, my projects are not being accessed by any other developers, so I fail to understand how a pending unaccepted change could be causing the failure.

This is a test example that I have created. Our actual project will be very large. Hence, the desire to limit loads on integration builds. We have logically divided the project into an SDK and a product that will consume and extend the SDK. If there exists opinions about other ways to build the SDK and deliver the result into another set of build processes for consumption I'm all ears.

The error means that if the changes in the change set is delivered
to the "HelloWorld Project" stream it will cause a conflict
in the target stream because there are newer changes (for Dist
component) in the target stream.

The current workspace has to resolve those conflicts before
delivering it to the stream. To resolve the conflicts, you have to
change the flow target of the component to the target stream, accept
any incoming changes, resolve the conflicts and then deliver the
changes. While resolving if you want to keep your version of the
change, you can run "scm resolve --checkedin" to retain
your change.


I assume you meant "HelloWorld Release 1.0" and Not
"HelloWorld Project". My build is checking into a
different stream. Assuming your post contained the mistake noted, it
implies that I must perform and action that I'm trying to avoid,
namely, performing a load operation on the HelloWorld Release 1.0
workspace just to check in a single change set. The example in
recipe 2 of http://jazz.net/library/article/195 does not show any
load or resolve action prior to checking the change to the other
stream. In addition, my projects are not being accessed by any other
developers, so I fail to understand how a pending unaccepted change
could be causing the failure.

This is a test example that I have created. Our actual project will
be very large. Hence, the desire to limit loads on integration
builds. We have logically divided the project into an SDK and a
product that will consume and extend the SDK. If there exists
opinions about other ways to build the SDK and deliver the result
into another set of build processes for consumption I'm all ears.