One thing to keep in mind is that a "synchronize" is not just a "build"
(even though it uses the build machinery in its implementation). But
there is an analogy that might help explain the behavior. Suppose that
as part of your build, you checked in some new changes, and then you
want the build to deliver those changes to some stream (in the
Synchronize case, the "new changes" are changes coming over from
ClearCase, and the "stream" is the synchronized stream). But now
suppose the stream you are delivering to has constraints, such as "there
must be a work item associated with any change set, and that work item
must be planned for the current release". The attempt by the "build" to
deliver the change set to the stream will fail unless that condition is
met (or unless that condition is removed from the stream).

That is what happened in your case. The project area containing the
synchronized stream had this constraint. So you either had to use a
work item template in the synchronized stream that satisfied this
constraint, or you had to remove the constraint (or change the owner of
the synchronized stream to be a project area without this constraint).
Also note that although changing the work item template will fix
subsequent sync requests, it will not "fix" the synchronize that failed
(it sounds like this is what you tried), because a new work item is
created (by copying the "template" work item) for each sync, so updating
the work item template does not update the work item actually associated
with the previous sync attempt.

Cheers,
Geoff


On 3/15/2012 4:57 AM, hajo62 wrote:

Thanks Geoff, that solved my problem.

From my point of view, it's not so easy to understand, that a Work
Item connected to an old Build inhibits
new builds to execute. If I saw correct, the synchronization
(connected to that Work Item) did occure, so that data later
synchronized would fit.