Received: from [192.168.0.73] (root@raven.ravenbrook.com [193.82.131.18]) by raven.ravenbrook.com (8.9.3/8.9.3) with ESMTP id TAA08594 for ; Fri, 27 Oct 2000 19:37:56 +0100 (BST) Mime-Version: 1.0 X-Sender: gdr@pop3 Message-Id: Date: Thu, 26 Oct 2000 20:25:22 -0700 To: p4dti-staff@ravenbrook.com From: Gareth Rees Subject: Alpha test report: Perforce, 2000-10-26 Content-Type: text/plain; charset="us-ascii" ; format="flowed" This is a report of issues discovered while installing and configuring P4DTI at Perforce on 2000-10-26. 1. In p4win, under Options -> Miscellaneous, there's a typo: "Tempoary" for "Temporary". 2. The line endings in README.txt on the 0.3.2 release CD-ROM are in Macintosh format. 3. On grrr.perforce.com, TeamTrack wouldn't run because it couldn't find the ODBC drivers. This is really TeamShare's problem, but the troubleshooting section of the administrator's guide needs a mention of possible lack of MDAC and other junk, and how to find it. 4. When we started the replicator, it reported "p4 info didn't report a recognisable version". On investigation, it turned out that the 'p4-client-executable' had a space in it and so Python couldn't run the program. Even when we tried putting quotes around the executable name in the command string it didn't work. In no case did win32pipe.popen return an error. 5. The p4 module doesn't raise an error when output would have been expected from Perforce but there was none. For example, p4 info always produces a result. (This might require the p4 module to know a bit too much about Perforce commands, since e.g. p4 jobs might produce no output -- this would be indistinguishable from not running at all, unless we can look at the result code of running the program.) 6. "p4 -G job -o" applies much more stringent tests than "p4 job -o". It won't even give you a form unless all the values are correct. This means that tricks like ones in Perforce's jobspec, where an illegal value like "setme" is specified as the default value for a select field, can't be used with the integration. 7. You have to be a Perforce super user if you want to be able to run "p4 counter logger 0". So the replicator needs to be a Perforce super user. The replicator should check for this and the administrator guide needs to say this. For customers who are worried about the replicator running riot over the repository, we may be able to work out a way of forbidding P4DTI-* from editing files. However, "super user P4DTI-wibble * -//..." didn't work. 8. The replicator replicates all the changelists to the defect tracker. Might this violate Perforce protections in some ways? Need to check this. 9. The replicator didn't create a counter when we tried it. The reason for this is that Chris had changed the server so that "p4 counters" and "p4 logger" output is now tagged. This is fine, but we need to rewrite the bits of the replicator that looks at the output of these commands. There's an issue here about which Perforce server versions we support. We could have found this kind of problem sooner if the functions had more assertions about the output they expect. 10. Checking all the changelists at startup is not acceptable. An organization may have tens or hundreds of thousands. First, the replication of changelists must be batched up so that it is as efficient as possible. Second, changelists should be replicated with some explicit instruction from the administrator. We might miss some, though. The consistency checker can look at them too. 11. TeamTrack lost the LAST_CHANGE record in the VCACTIONS table. No idea why this happened. 12. There's a bug in the "Add job fix" dialog box in p4win. Newlines in the job description show up as black rectangles. 13. E-mail messages from the replicator aren't wrapped. We want to support e-mailers that don't automatically wrap lines, so we should wrap the messages ourselves. 13. When the replicator overwrites an entity, it puts any overwritten information in the e-mail. So if it deletes or updates a fix it should send it in the e-mail. 14. The replicator shouldn't exit when it can't look at a job. 15. The replicator should notice when one of the fields to replicate isn't in the jobspec. 16. TeamTrack wouldn't show us fixes or filespecs, even though we were logged in as a user in the group specified in the VC Update Group registry key. 17. If the replicator fails to send e-mail to report the resolution of a conflict, it tries to send e-mail to explain that it couldn't send e-mail. This is probably the wrong thing to do. 18. The P4DTI_ACTION field could be a single select field, with possible values. But then the replicator would have to know how these values correspond to keep, discard etc. But it can do that because we'll have some functions for replicating single select fields, so we'll have a cache of the SELECTIONS and FIELDS table anyway and we'll be able to work out how they correspond. 19. The replicator should report error when third item in an element of the 'replicated-fields' list is bogus (that is, there should be a fixed set of these). These items could be methods or functions or something instead of strings. 20. We should log a great deal more stuff than we do, but have a minimum log level in the configuration. That will make testing much easier (you just turn up the log rather than adding verbose instructions to the code like we did today).