Adapting the P4DTI to synchronize jobs between two Perforce servers

1. Introduction

This document sketches out some of the design issues involved in adapting the P4DTI to synchronize jobs between two Perforce servers. It's based on [RB 2001-03-14].

The intended readership is project developers.

This document is not confidential.

2. Design notes

The replicator doesn't care what kind of defect tracker it's replicating to. It could be another Perforce server. In fact, it was always intended for the code in replicator.py to be more symmetric between the defect tracker and Perforce, by putting Perforce code into the class dt_perforce, offering the same interface as any other defect tracker.

So what would be required to write the dt_perforce class? This is set out in [GDR 2000-10-16].

From [GDR 2000-10-16, 3.5], we need to implement only the new_issues feature.

From [GDR 2000-10-16, 4.1]:

• Perforce might not want to have extra fields added to their jobspec. The replicator identifier and server identifier could be faked, by relying on replicator_p to tell us which jobs are replicated by the replicator. Could we avoid storing the corresponding jobname (by querying Ravenbrook's Perforce server using p4 jobs -e "P4DTI-issue-id=...")?

From [GDR 2000-10-16, 4.5]:

• We can use the p4 counter mechanism to store record the last logger entry we looked at. (But if we use p4 logger to get changes, then this uses up a scarce resource: there can only be one consumer of the logger.)
• We can avoid storing changelist_url, job_url, and p4_server_description since we don't plan to provide a defect tracker interface [GDR 2000-10-16, 10].

From [GDR 2000-10-16, 7.1]:

• all_issues can use p4 jobs -e date >= start_date.
• changed_entities and mark_changes_done are already written as methods in the replicator class.

From [GDR 2000-10-16, 7.2]:

• We can get around the need to propose anything sensible in corresponding_id by always running with the use_perforce_jobnames configuration parameter turned on.
• rid could be faked if Perforce weren't willing to have a P4DTI-rid field in their jobspec.
• setup_for_replication needs to store the Ravenbrook jobname in the Perforce job.
• update might need to ignore the user: it will be impractical to replicate user accounts.

From [GDR 2000-10-16, 7.5]:

• We need a state translator [GDR 2000-10-16, 7.5.1], but this is probably a no-op.
• We need a user translator [GDR 2000-10-16, 7.5.4]. There are no clashing users between the two systems. But we could do something like translating users from the other system to e-mail addresses for clarity at both ends.

From [GDR 2000-10-16, 7.5]:

• The field_map will be quite complex. Perforce have a description field, but no title field or separate analysis field. We could put the title in the first line, and mark the analysis somehow in the description.

A. References

B. Document History

Copyright © 2002 Ravenbrook Limited. This document is provided "as is", without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this document. You may make and distribute verbatim copies of this document provided that you do not charge a fee for this document or for its distribution.