Issues for Perforce following alpha testing

1. Introduction

This is a list of all the open issues that Perforce needs to look at and resolve, as of 2000-11-09, following alpha testing (see [RB 2000-11-04] for a summary of the alpha programme).

I have put the issues into categories by priority. The terms "critical", "essential", "optional" and "nice" are defined in [RB 2000-05-05, 2.2]. In particular, a critical issue is one which may cause the project to fail if it is not successfully resolved.

We need a commitment from Perforce to a schedule to fix the critical issues in time for the beta release in early December 2000. If Perforce can't meet such a schedule, then we need to know as soon as possible so that we can work out what to do for the beta. We'd like Perforce to schedule fixes for the essential issues in time for release 1.0 of P4DTI in February 2001 (all but one of these involve documentation rather than code changes). We need Perforce to send us server and client releases as changes are made so that we have software to test against.

The intended readership is management and developers at Perforce Software.

This document is not confidential.

2. Critical issues

2.1. There is no reliable way for the replicator to distinguish its changes to jobs from changes made by other Perforce users

The replicator has an "always" field called "P4DTI-user" with "Preset-P4DTI-user: $user". It relies on this field being updated each time the job is changed. In order for this to work, this field must be updated whenever the job is affected by an operation. That includes:

1. Editing the job with "p4 job".

2. Associating a fix with the job by using "p4 fix -s status -c 1234 jobname" (for a submitted changelist) or by submitting a pending changelist. Note that this might not even change the job's status.

3. Deleting a fix with "p4 fix -d -c 1234 jobname".

See Ravenbrook's job000016.

2.2. When you delete a fix with "p4 fix -d -c 1234 jobname", no logger entry is added for the affected job

See Ravenbrook's job000013.

2.3. The fixes keyword can't be set on submit (except to "closed")

See Ravenbrook's job000007.

2.4. "p4 -G jobspec -o" doesn't work

Note that it is essential that "p4 -G jobspec -i" work too.

See Ravenbrook's job000004.

3. Essential issues

3.1. You can't fix the default changelist

Many alpha testers wanted to be able to associate a job fix with the default changelist. They generally work only with the default changelist and don't like the extra step of creating a numbered changelist in order to be able to associate it with a job.

See Ravenbrook's job000040 and [GDR 2000-11-01, item 3].

3.2. Fixes are hard to use from p4win

1. You can't select a job in the jobs pane and discover the fixes associated with it (no equivalent of "p4 fixes -j jobname").

2. You can't look at the fixes relation in general (no equivalent of "p4 fixes"), or filter them by filespec (no equivalent of "p4 fixes ...").

3. You can't make a fix with a keyword other than "closed".

See Ravenbrook's job000007 and [RB 2000-11-04, 5.1].

3.3. Are there required values for the job's Status field?

It seems as though Perforce insists on there being job statuses "open" and "closed". (New jobs get "open" status by default; fixed jobs get "closed" status by default). Is this correct? The Perforce System Administrator's Guide doesn't provide the answer.

This is a need for documentation rather than a change. We need to be able to tell users of the integration what to do.

See [GDR 2000-10-23, item 10].

3.4. Syntax of jobspecs

The Perforce System Administrator's Guide is not very specific about the jobspec syntax. In particular:

1. If I want to have values for a select field that contain spaces or slashes, can I quote them? What if I want quotes as well? Can I escape the quotes?

2. How can I specify an empty string for the default value of a line or text field? How does $blank work?

Again, this is a need for documentation rather than a change.

See [GDR 2000-10-27, item 19] and [GDR 2000-10-30, item 6].

3.5. Notice of changes to server output

The 2000.2 alpha release that Perforce is running on the computer.perforce.com test server produces tagged output for "p4 logger" and "p4 counters". This is good, but it broke the 0.3.2 release of the integration which was expecting untagged output.

I will adjust the replicator so that it can cope with both tagged and untagged output for these commands (so as to support both Perforce 2000.1 and 2000.2).

Are there any other proposed changes to tagging that we need to know about in future releases?

Again, this is a need for documentation rather than a change.

See [GDR 2000-10-26, item 9].

4. Optional issues

4.1. Bug in the "Add job fix" dialog box in p4win

Newlines in the job description show up as black rectangles.

See [GDR 2000-10-26, item 12].

4.2. Can't have underscores in jobview

At Quokka Sports, Rob could set up a job filter (in p4win, Job -> Job Filter) of the form "Owner=rob", but not "Owner=rob_surname". Is there a problem with underscores in the jobview?

See [GDR 2000-11-03, item 3].

4.3. Problems with p4win job dialog

The "Edit job" dialog in p4win has these problems:

1. If there are too many fields, the later ones disappear off the bottom of the screen and you can't see or edit them.

2. Fields with type "line" and "word" take no account of the length of the field, so that a field with length 80 is still seen through a 20-character wide edit box.

5. Nice issues

5.1. It would be nice if fixes showed in the revision history (in p4win) or the output of "p4 filelog"

See [GDR 2000-10-30, item 13].

5.2. Are "p4 -G job -o" checks possibly too stringent?

The "p4 -G job -o" command applies much more stringent checks on the validity of the data than "p4 job -o". It won't even give you the job data unless all the values are correct.

A consequence of this is 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. So we won't be able to support Perforce's own jobspec.

See [GDR 2000-10-26, item 6].

5.3. Bizarre jobspec behaviour

We tried creating a jobspec with the following stuff in it:

Fields:  101 Job word 32 once
Preset-Job: new

This allowed us to create a job such that "p4 jobs" showed its name as "jobnnnnnn" but "p4 job" showed its name as "new"! This was surprising since it suggests that field 101 is not actually the jobname, but only a copy of it.

I think that Perforce should reject jobspecs like the one above where the type of the "system" fields is wrong.

See [GDR 2000-11-01, item 11].

5.4. In p4win, "Add new job" gives you a different layout from "edit job"

See [GDR 2000-11-03, item 9].

A. References

B. Document History

Copyright © 2000 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.