Symptom. An organization already uses Perforce jobs and wants to migrate them to the defect tracker, but can't do that.
Cause. The P4DTI doesn't do this yet. See the migration design for an analysis of the difficulties.
Workaround 1. Wait for the next but one release of the P4DTI, estimated for 2001-10, which will support migration from Perforce jobs to the defect tracker.
Workaround 2. Enrol as a beta-tester for the migration, which we plan to take place in 2001-08.
Workaround 3. Get jobs into the defect tracker in some other way. With only a few hundred jobs its probably economical for an administrative assistant to do it by cut and paste. Alternatively, one could use SQL server or MySQL to put the jobs directly into the defect tracker's database.
Symptom. The owner of a job receives an automatically generated e-mail message from the replicator looking like this:
Defect tracker issue 'BUG12345' and Perforce job 'BUG12345' have both changed since the last time the replicator polled the databases. The replicator's conflict resolution policy decided to overwrite the job with the issue.
The replicator has therefore overwritten Perforce job 'BUG12345' with defect tracker issue 'BUG12345'. See section 2.2 of the P4DTI User Guide for more information.
Cause 1 and solution. This e-mail can be caused by users simultaneously changing a defect tracking issue and the corresponding Perforce job, as described in section 2.2 of the P4DTI User's Guide. This is correct behaviour. In this case the user who changed the job should check to see if their changes have been lost by the overwrite. If so, they should edit the job again and make their changes again. Their changes to the job are included in the e-mail, so nothing has been lost.
Cause 2 and workaround. If someone makes two changes to an issue in the defect tracker in quick succession, the first change may be replicated successfully to Perforce. But when the replicator next polls the servers, it sees that the issue has changed again, but so has the corresponding job (it sees the change that it made itself on the previous replication). So it thinks both have changed and it overwrites the job with the issue. No harm is done by this feature of the P4DTI; it's just annoying to be sent e-mail needlessly. Users should just ignore these e-mails.
The underlying cause is that Perforce doesn't update the "always" fields in a job when someone affects that job by making or deleting a fix. This means that the replicator can't accurately tell who last changed a job, and so it has to consider changes that it made on previous replications as being candidates for replication. This is Perforce job 4308.
Symptom. The integration administrator receives a sequence of automatically generated e-mails from the replicator that look like this:
The replicator failed to poll successfully, because of the following problem:
Exception:
TeamShare API error: SOCKET_CONNECT_FAILED: Socket Connect failed.
A variety of errors may appear here.
Cause. The replicator has become stuck and can make no more progress. Possibly it can't connect to one or both of the servers; possibly it can't replicate issues because it has been misconfigured. The replicator backs off, doubling its waiting time each time it encounters the problem. When the problem is fixed it will continue normally.
Solution. The replicator can't continue until the problem is fixed. The administrator must identify and fix the problem. Section 11.2 of the P4DTI Administrator's Guide is a good place to start.
Symptom. A user fixes a job using p4 fix or its equivalent in the GUI. However, that user doesn't have permission to change the job, so the replicator sets the job state back to its old value. But p4 fixes still shows the fix.
Cause. The replicator doesn't revert fixes when it reverts the job. The reason for this is that it can't be sure that the fix caused the change in the job; the fix might have been perfectly legitimate even though the change to the job was wrong.
Workaround. If the fix was correct, get someone who has permission to update the job state in Perforce, or transition the corresponding issue in the defect tracker. If the fix was incorrect, delete it from Perforce with p4 fix -d.
Symptom. The replicator fails to start, reporting an authentication failure from its SMTP server. (It would be nice to have the actual error message here, but I didn't record it at the time.)
Cause. The mail server is using the ESMTP protocol and requires clients to authenticate themselves. The P4DTI doesn't support ESMTP authentication.
Workarounds. You can stop the replicator from attempting to send e-mail by setting the smtp_server configuration parameter to None. But this is a bad idea because users won't be informed when they make illegal changes in Perforce, and the administrator won't be informed when the replicator can't replicate. A better alternative would be to run an ordinary SMTP server especially for the replicator to use.
Symptom. This happens only in the Bugzilla integration. The integration administrator receives a sequence of automatically generated e-mails from the replicator that look like this:
The replicator failed to poll successfully, because of the following problem:
Exception:
Perforce error: Error in job specification. Missing required field 'Assigned_To'.
Cause. The "Assigned_To" field has become empty in Bugzilla; we believe that this can't happen in Bugzilla 2.10, so that's why it causes an error in the replicator. So this can only happen at a site which is not running Bugzilla 2.10, or which has changed the way Bugzilla 2.10 works, or where someone has edited the Bugzilla database directly, bypassing Bugzilla.
Workaround. Assign the bug to someone in Bugzilla.
If you're sure that you're running a vanilla Bugzilla 2.10, then please try to work out how the "Assigned_To" field became empty and report this to Ravenbrook so that we can fix the problem.
Symptom. In the TeamTrack integration, if you try to assign a job in Perforce to a Perforce user who doesn't have a TeamTrack licence (by editing the Owner field), then the replicator refuses to replicate it; it resets the Owner field and sends e-mail.
Cause. To get the benefit of TeamTrack features, TeamShare insist that you buy TeamTrack licences. We agreed with TeamShare that the P4DTI would respect this policy; see [GDR 2000-08-18, 3.3.1].
Solution. Buy new TeamTrack licences for all users who need to use TeamTrack features (whether directly or via the P4DTI).
Workaround 1: Restore original copies of bug_form.pl and defparams.pl from the appropriate Bugzilla distribution. Then apply the patch for your release of Bugzilla and the P4DTI. (But don't do this if you've customized these files.)
Workaround 2: If you have customized these files, then you need to back out both patches with patch -R < patch-file and restore the one you need. You probably need to get the old patch file by downloading the old P4DTI release again.
Workaround: If a user has such a bug in their Bugzilla database, they can enable its replication by using MySQL to put some text into the guilty longdescs row. (e.g. update longdescs set thetext='No description.' where bug_id = 371;). This is not very satisfactory.
Symptom:Bugzilla integration fails and sends the following e-mail message:
(P4DTI-8647) The replicator failed to poll successfully, because of the following problem:
[Errno 5] Input/output error
Diagnosis:The replicator is not being started with the P4DTI startup script, but by hand from a shell. The replicator is then placed in the background and the shell is exited. When the replicator subsequently tries to write log messages to its standard output, it cannot do so and fails with this message.
Workaround: Change the way in which you invoke the replicator so that standard output is redirected to a file or to /dev/null. For instance:
$ python run.py > /dev/null
(note that the standard P4DTI startup script invokes the replicator in this way). Or:
$ python run.py > logfilepath
Symptoms. The P4DTI fails to start and produces the error message TeamShare API error: SOCKET_READ_ERROR: Authentication Failed. No user information..
Cause. TeamTrack is not accepting authentication information from the HTTP header because the TeamTrack administrator has turned off this feature.
Solution. Turn on the "Accept Info From Browser/Header" setting (in the TeamTrack Administrator, choose "Settings" from the "Options" menu; choose the "Server" tab; turn on the "Accept Info From Browser/Header" checkbox). Note that you do not have to turn off "Accept Info From Form/URL/Cookie". If both boxes are checked, TeamTrack will try to get the authentication information from a cookie first, then it will try the HTTP header.
Symptoms: Using the Bugzilla integration, when someone changes a bug in Perforce, e-mail notifications aren't sent.
Cause: You haven't specified anything for the bugzilla_directory configuration parameter, or you've specified the wrong directory. The P4DTI can't find the processmail script which sends the e-mails.
Solution: Fix your setting for the bugzilla_directory configuration parameter.
TeamTrack 5.01 (build 50111) is not supported by the P4DTI.
Symptoms: The P4DTI stops with an error message from the MySQL database of the form (1062, "Duplicate entry '532232' for key 2").
Cause: Your MySQL database has been corrupted, either by a bug in MySQL or by an operating system or disk error.
Solution: You can check, and possibly repair, the affected tables with the "check table" and "repair table" commands in MySQL. See http://www.mysql.com/doc/R/e/Repair.html.
If you can't repair the problems with the "repair table" command,
then if the only affected table is p4dti_replications, you
can just drop this table and restart the P4DTI, when the table will be
recreated. Note that all bugs changed since the
start_date will be examined for replication to their
corresponding issues again. But if there are other affected tables,
you may have to resort to backups.