Content
View differences
Updated by Jens Ulferts over 9 years ago
The following scenarios for work packages are not prevented:
A follows B follows C follows A
A follows B follows C blocks A
A has child B follows C follows A
There might be other scenarios not known yet.
As dates of work packages that are dependent of one another can influence each other, this can cause an infinite loop of trying to update the date of a following work package (which is only terminated with an exception by ruby).
When fixing this, we also need to take a look at the relationships existing in a given installation as they might already be corrupt.
There is a paper on an algorithm for determining circular dependencies http://www.cs.tufts.edu/comp/150GA/homeworks/hw1/Johnson%2075.PDF which we might want to follow.
**Steps**
- Create three work packages A, B, C
- Go to A -\> Relations
- Set to precede B
- Go to B -\> Relations
- Set to precede C
- Go to A -\> Relations
- Set to follow C
Note that it is not prevented to do the following as the last step
- Go to C -\> Relations
- Set to precede A
A follows B follows C follows A
A follows B follows C blocks A
A has child B follows C follows A
There might be other scenarios not known yet.
As dates of work packages that are dependent of one another can influence each other, this can cause an infinite loop of trying to update the date of a following work package (which is only terminated with an exception by ruby).
When fixing this, we also need to take a look at the relationships existing in a given installation as they might already be corrupt.
There is a paper on an algorithm for determining circular dependencies http://www.cs.tufts.edu/comp/150GA/homeworks/hw1/Johnson%2075.PDF which we might want to follow.
**Steps**
- Create three work packages A, B, C
- Go to A -\> Relations
- Set to precede B
- Go to B -\> Relations
- Set to precede C
- Go to A -\> Relations
- Set to follow C
Note that it is not prevented to do the following as the last step
- Go to C -\> Relations
- Set to precede A