| Title | There's no way to re-start replication |
| Status | closed |
| Priority | essential |
| Assigned user | Richard Brooksby |
| Organization | Ravenbrook |
| Description | If things get in a mess or the configuration is changed then the administrator may want to re-replicate everything as if he were installing from scratch. We don't provide anything like that. |
| Analysis | We definitely need a way to reset as much as possible and re-start the system from scratch, especially if we're generating the jobspec. Of course we can't delete the fixes data, so we can't delete all the jobs completely. RB 2000-11-21. Yes we can! The fixes get replicated back from the defect tracker. GDR 2000-12-04. I've written a method replicate_all_dt_to_p4 that could form the basis for a solution to this job. RB needs to think about if this is the right thing to do and if so how to package and document it. GDR 2000-12-04. |
| How found | manual_test |
| Evidence | <http://www.ravenbrook.com/project/p4dti/doc/2000-10-31/mahi-alpha-test/> item 3< http://www.ravenbrook.com/project/p4dti/doc/2000-10-31/mahi-alpha-test/> item 8 |
| Observed in | 0.3.2 |
| Test procedure | <http://www.ravenbrook.com/project/p4dti/master/test/test_p4dti.py>, section 8.1 |
| Created by | Richard Brooksby |
| Created on | 2000-11-21 16:22:13 |
| Last modified by | Gareth Rees |
| Last modified on | 2001-12-10 19:01:33 |
| History | 2000-11-21 RB Created from sources (see evidence) 2000-11-22 RB Added more evidence from Mahi Networks. 2000-12-04 GDR Added correction to RB's claim. Assigned to RB. |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 5819 | closed | 2000-12-11 15:50:11 | Gareth Rees | Merged changes from version 0.4 back to master. |
| 5694 | closed | 2000-12-08 12:56:30 | Gareth Rees | Added new script refresh_perforce.py that deletes all jobs and re-replicates jobs and fixes from the defect tracker. |
| 5388 | open | 2000-12-04 18:41:38 | Gareth Rees | Removing resolver role from the integration: Tidied up the replication and mailing methods to make this part of the replicator clearer. Changed replicate_issue_to_job() to replicate_issue_dt_to_p4() and replicate_job_to_issue() to replicate_issue_p4_to_dt() for consistency with other method names. Added new methods overwrite_issue_dt_to_p4() and overwrite_issue_p4_to_dt(), which are wrappers around the above methods that also e-mail the affected parties. In order to be able to e-mail the owner of a job, added the replicator method user_email_address for getting a Perforce user's e-mail address and the replicator configuration parameter job-owner-field that names the owner field in a job (the automatic configuration generator specifies 'Owner' for this). Removed the mail_administrator method() (use mail instead), and improved the mail() method. Improved many log entries by using issue.readable_name instead of issue.id. Re-organized and documented the replicate() function. It's no less complicated than it was before, but I think it's easier to understand. Functions like replicate() and replicate_issue_p4_to_dt() no longer return a meaningful error code. They either return or throw an exception. Changed conflict_policy so that it always returns 'dt'. This is the key change that removes the resolver's role. Changed the handling of errors to support the change in the conflict policy. There's now no need for conflict_error, so this is gone. The reverting of jobs to the corresponding issue is handled by the revert_issue_dt_to_p4() method: this ensures that it gets called in the correct place only (that is, normal replication from Perforce to the defect tracker has failed). The replicate_many() method no longer does any handling of errors. All other errors are caught by the run() method so that the replicator can keep on going, except AssertionError and KeyboardInterrupt, both of which stop the replicator. |