| Title | TeamTrack transition not replicated from P4D 2002.1 beta (29455) on submit of pending changelist |
| Status | closed |
| Priority | essential |
| Assigned user | Nick Barnes |
| Organization | Ravenbrook |
| Description | When a pending changelist with a fix record is submitted, the appropriate transition doesn't take place on the corresponding TeamTrack case. This problem has only been observed with P4D 2002.1 beta/29455 and TeamTrack 5.5 (build 55017); it is not observed with P4D 2001.1, and was fixed before the 2002.1 release of Perforce (in P4D 2002.1/31756). The case history doesn't show the transition. The change to the changelist status (pending -> submitted) is replicated, and shows up in the case. If the same job is fixed with a previously submitted changelist, then the transition is displayed properly. |
| Analysis | The output of "p4 logger" has changed between P4D 2001.1 and P4D 2002.1/29455 in the case where you submit a pending changelist which has an associated fix. Suppose the Perforce logger is empty and I run "p4 submit -c 12345" and that changelist 12345 will close job000123 when submitted. Then in Perforce 2001.1 I get these two log entries: 1 job job000123 2 change 12345 But in Perforce 2002.1/29455 I get only one log entry, namely: 1 change 12345 So the P4DTI doesn't know that the job has changed, and so doesn't replicate the change to the status field. This is clearly a bug in P4D 2002.1/29455. The P4DTI could work around it by forcing the replication of jobs fixed by changelists which are replicated. This might have undesirable side effects, such as the uncessary replication of jobs when in fact only the changelist description was edited. It would be better to fix the problem in Perforce. Our existing automated test for fix-on-submission (test_p4dti.py section 10.3, part of the lifecycle test) didn't pick this up because the test case does too much between consecutive polls (it creates the pending changelist, makes the fix, and submits the changelist). Making the fix adds the job to the logger output, so the next poll replicates both the job and the changelist. This is not very realistic: almost always there will be a poll between making the fix and submitting the changelist. The test should be improved so that it makes more polls and checks the results of each one. |
| How found | customer |
| Evidence | Perforce job job007392 <http://info.ravenbrook.com/mail/2002/03/20/19-51-00/0.txt> |
| Observed in | 1.4.0 |
| Created by | Nick Barnes |
| Created on | 2002-03-21 11:00:42 |
| Last modified by | Nick Barnes |
| Last modified on | 2002-04-29 11:35:50 |
| History | 2002-03-21 NB Created. 2002-03-21 GDR Improved analysis. |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 27700 | closed | 2002-03-28 10:04:16 | Nick Barnes | Added P4D 2002.1 beta servers (31756). |