Stuart Ballard wrote:
>
> Gervase Markham wrote:
> >
> > > 2) Couldn't this be accomplished more cleanly by adding a num_dups field
> > > to the bug itself?
> >
> > No, because if something is un-dupped you get trouble.
>
> Why doesn't doing this just involve the reverse of the algorithm for
> dupping: subtract a.num_dups+1 from b.num_dups?
>
> I've thought about this (on and off) since I first read your posting
> several days ago, and I can't think of a case that would be terribly
> hard to handle. Provided that both dupping and undupping propagates its
> changes through bugs that are already dupped, I can't find a case that
> doesn't work.
Bugs A and B are marked as dups of Bug C. C has a dup count of 2.
C is marked as a dup of D. D has a dup count of 3.
E is now marked as a dup of C. C has a dup count of 3.
You might like to update D's dup count as well, but you can't, because the
only place in C where it's recorded that it's a dup of D is the comments,
and parsing comments is icky and horrible.
F is now marked as a dup of C. C has a dup count of 4.
C is reopened.
The algorithm would then not know what size dup count to remove from D now
that C had been reopened. The correct answer is 2, because that's what the
dup count was when C was dupped against D. But that number is no longer
stored anywhere.
You could then argue that each bug should store the number of the bug that
it's a dup of, if any, so that you could follow dup chains, updating the
count. That is an alternative approach, but would have involved changing
the schema of the main "bugs" table in Bugzilla, which is something not to
be done lightly.
Gerv
