|Title||Resolving a Bugzilla bug without setting the resolution always causes a conflict|
|Assigned user||Nick Barnes|
|Description||Resolving a Bugzilla bug without setting the resolution always causes a conflict.|
Set the status to "RESOLVED" in Perforce, then poll the replicator twice. On the second poll, the job is updated to a conflicting state.
|Analysis||Bugzilla integration can't identify its own changes to Bugzilla|
When the Bugzilla integration is identifying changed issues, it currently includes issues which it has changed itself. This can obviously lead to problems, including bogus conflicts.
We currently check the bug record's timestamp against the time of the start of the last replication. We need to do better than this. For a start, we should check the bugs_activity table instead of the bugs table timestamp (which is set even by empty updates).
This is related to job job000089 (we don't update the bugs_activity table). In the absence of a fix for that job, this job would be fixed simply by checking the bugs_activity table. Once that job is fixed, we need to do better.
Two possible approaches:
1. when adding to the bugs_activity table, we can have distinguished values of some sort, which can be spotted and excluded. For instance, we could add text to the "old value" column (which is only used for reporting conflicting changes to Bugzilla users), which could be identified.
2. (less icky): have a new table and add changes to the bugs_activity table and the new table at the same time. Then replication activity can be excluded with a suitable join.
|Evidence||I just know.|
|Created by||Nick Barnes|
|Created on||2000-12-04 13:59:01|
|Last modified by||Gareth Rees|
|Last modified on||2001-12-10 19:08:33|
|History||2000-12-04 NB Created.|
2000-12-04 RB Described user impact and moved existing description to analysis.
|5446||closed||2000-12-05 13:47:18||Nick Barnes||Typo in last changelist.|