I think the task-based methodology is cool and very powerful but there are some issues and concepts that confuse me.
there is a simple comprehension question:
let there be a root object foo.c (Version: 1 , Release: test/1.0)
-Developer A creates a new Task for release test/1.0 and checks out the object foo.c. The new version is foo.c-2. The developer wants to backup the temporary changes and checks in the object (foo.c-2 integrate). The Task is stil "assigned"! Then the developer continues his work and has now the version foo.c-3 (working). Both versions are not "completed", the task is still "assigned" and therefore "invisible" for the update rules of the other collaborative projects for release test/1.0.
-Developer B does an update in his own project and then checks out the object foo.c -> foo.c-1.1.1 (working). Developer B is ready with his changes and tries to complete his own task and there comes the parallel notification: he is forced to merge. Developer B is not very happy and tries to kill his BuildManager (me) :ohmy:
Why is there such parallel notification? There is not really a parallel conflict beacuse Task A is still not completed. The only completed Task at this point must be Task B.
Why must Developer B merge his own completed changes with the temporary (not completed and maybe inconsistent!!!) changes of Developer A. The idea of the task-based methodology is basically that only completed changes (tasks) count.
Is there any way to change this behaviour??
We are using Synergy 6.5 SP2 with the standard process rules and the parallel restriction: allow parallel checkout, disallow parallel checkin
Thanks in advance!!!
Knut
