| Title | Double replication causes many conflicts |
| Status | closed |
| Priority | essential |
| Assigned user | Gareth Rees |
| Organization | Perforce |
| Description | There is no reliable way for the replicator to distinguish its changes to jobs from changes made by other Perforce users. This means that everything replicated from the DT to Perforce is then replicated back again, and conflicts are very likely when making edits in the DT in quick succession. |
| Analysis | When I do a "p4 fix -s status -c 1234 job000001", the status of the job is changed, but "always" fields in the jobspec that record the time the job was last modified or the user who last modified the job are not changed. This means that the job description is inconsistent. This thwarts my design for distinguishing changes made by the replicator from changes made by other Perforce users (see <URL: http://www.ravenbrook.com/project/p4dti/master/design/replicator/#section-4.5>).It is essential that the replicator has some way of distinguishing its own changes. If it can't, then every replication to Perforce will be followed by a needless replication back to TeamTrack of the information just replicated. This doubles the rate of conflicts, which means that we risk not meeting requirement 1. I can think of two changes to Perforce that would meet my requirement: 1. When a user does a "p4 fix -s status -c 1234 job000001", Perforce (in addition to changing the job status) does the equivalent of "p4 job -o job000001 | p4 job -i" to make sure that "always" fields in the jobspec are consistent with the changed status. 2. "p4 logger" reports the user who made the change that caused the log entry. This is also the cause of job000042, job000086 and job000133. Another use for the P4DTI-user field is to identify the user who last changed the job, so that they can be e-mailed when the job is overwritten (and so their data is lost). We can't reliably do this at the moment, and it will be very hard to reliably do this if solution 2 above is adopted. But solution 1 is OK. GDR 2000-11-28. This is reduced in severity by the adoption of the "defect tracker wins" conflict resolution policy. With this in place, you don't get the conflicts, but you do get unnecessary e-mail. GDR 2000-12-06. It seems possible that the replicator could identify logger entries which correspond to changes to jobs which the replicator makes itself, simply by remembering when the replicator makes a change to a job. Then when asking the logger for recent entries, this set of expected entries could be culled from the list before use. For instance suppose we updated jobs 37 and 94 since the last time we queried the logger. This time we query the logger it says "job 37, job 94, job 94, job 32". We cull the job 37 entry and one of the job 94 entries and keep the job 32 entry and the other job 94 entry. I think this is at least worth a try. NB 2001-03-06. GDR 2001-06-19: This defect is present in P4D/NTX86/2001.1beta/22346. GDR 2001-08-07: This is Perforce job 4308. |
| How found | manual_test |
| Evidence | <http://info.ravenbrook.com/mail/2000/10/06/11-12-52/0.txt>< http://info.ravenbrook.com/mail/2001/03/06/16-24-50/0.txt>We observed this at Quokka Sports. RB 2000-11-28 |
| Test procedure | <http://www.ravenbrook.com/project/p4dti/master/test/test_p4dti.py>, section 22 |
| Created by | Gareth Rees |
| Created on | 2000-10-10 11:06:04 |
| Last modified by | Gareth Rees |
| Last modified on | 2002-01-28 18:17:56 |
| History | 2000-10-06 GDR Created 2000-11-28 RB Set priority to "essential" to match GDR's assessment. Split text into description and analysis. Matched against Perforce job job 4308. 2000-11-28 GDR Added note about e-mailing the user who last changed the job. 2000-12-06 GDR Added note about reduction in severity and connection with job000042 and job000133. 2000-12-07 GDR Moved analysis from Description to Analysis. 2001-03-06 NB Note on idea about culling the logger list. 2001-06-19 GDR Added analysis for Perforce 2001.1 beta. |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 26176 | closed | 2002-01-28 20:50:48 | Gareth Rees | Don't replicate changes in Perforce that we made in the previous poll. Perforce interface records server changelevel. In Perforce 2002.1, use the P4DTI-user field as an accurate guide as to who last edited the job. |