Meeting with Chris Seiwald, 2000-08-22

Gareth Rees, Ravenbrook Limited, 2000-08-22


1. Introduction

This document describes a meeting between Gareth Rees and Richard
Brooksby of Ravenbrook Limited and Chris Seiwald of Perforce Software on
2000-08-22.

The purpose of the meeting is to discover Chris' changes to the Perforce
server and clients that are required for the defect tracking integration
project (and outlined in [RB 2000-08-08]).

The readership of this document is the P4DTI project staff.

This document is not confidential.

Everything Chris has done so far is in the beta downloads and will be in
the 2000.1 release on 2000-09-01.


2. Fixes keyword

See change 16293 on perforce.perforce.com:1666.

Fixes relation extension is not documented as part of the release, only
in the change description.  The fixes relation now has a status field,
which is a string field.  It's default value is "closed".  By doing an
appropriate option to the fix command "p4 fix -s status" you can change
the status.  It is not keyed on the status so if you do a fix on the
same job/changelist pair with a different status then it replaces the
old status.

The status is used to set the job status when the change is submitted. 
(If the change is submitted the fix changes the job status immediately.)
If the status is not in the allowed values for the job status, it goes
through anyway.  (Later attempts to edit the job might fail).  The new
status is not exposed through the fixes command (that would break the
GUI).

The user, client and date reported by the fixes command are now the
user, client and date who made the fix (it used to be the
user/client/date who submitted the change).

Currently there is no way to choose a status when you submit a change
(this would have been a major change to the GUI).  This is not good.
People can work around by creating a pending changelist, using "p4 fix" to
associate it with a job and a status, and then submitting the pending
changelist.

Chris says he could add a configurable default status (that is, not
closed) in about a week, but allowing people to specify job status in
the form is hard.


3. Determining when things have changed.

See change 16249 on perforce.perforce.com:1666.

The commands are "logger" and "counter".  They are documented in "p4
help".  The "logger" command dumps the event log for jobs and changes.
Note that the logger can track only one consumer of the log, since it
deletes entries after they have been read.  This means that we can only
have one replicator per Perforce server.

Fixes are not logged, but you can always tell if a fix has happened
since it changes a changelist and a job.

We need to check a lot of cases: when a change is renumbered, is enough
information recorded to determine what happened?

When you do a "p4 edit -c change-number", this gets logged since it
affects the changelist table.


4. Using pending changelists

Pending changelists aren't supported by the plug-ins (which don't have
any workflow support).  Perforce made a decision to require users to go
out of the IDE if they want to use pending changelists.

We will support pending changelists in the integration, but we won't be
able to require people to use them, since they may be using IDEs.

Chris believes that "p4 fixes -j jobname" will give you all changelists
associated with the job, even pending changelists.  The reason why "p4
jobs //..." doesn't give pending changes is that wildcard expansion runs
against the table of submitted revisions.  This can't be changed
quickly.  Perforce would like to change it in the long run.

There's no quick way to find all pending changes.  "p4 changes -s pending"
scans the whole table (this may be slow).  But "p4 opened" only gives you
open files -- you may have pending changelists with no open files.


5. Tagged output

Not every Perforce command can produce its output in a properly tagged
format.  Commands have been changed to produce tagged output as they are
needed.  So we may find some commands that produce output as a big piece
of text.


6. Tracker-client architecture

Chris thinks it would be best to use p4web rather than a plug-in. The
defect tracking interface would generate URLs that point to the p4web. 
Configuration might be awkward.

But the user requirement is to make it easy to do simultaneous check in
and submit.  The p4web option isn't really any better than just asking
users to switch to p4win or to the command line to do the submit.

We need to investigate just how important the user requirement for
simultaneous submit and transition through the defect tracker's web
interface actually is.


7. Two-phase commit

There's currently no interface in Perforce for locking a submit with the
option of rolling back the whole thing.  Chris thinks it would be
possible to change the server to provide locking just before commit
(after all the repository files have been transferred) with the option
of rolling back (since at that point no metadata refers to those
revisions).


A. References

[RB 2000-08-08] "P4DTI design meetings with Perforce, 2000-07"; Richard
Brooksby; Ravenbrook Limited; 2000-08-08.


B. Document history

2000-08-22  GDR  Written during meeting.


Copyright (C) 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.

$Id: //info.ravenbrook.com/project/p4dti/doc/2000-08-22/perforce-meeting/index.txt#1 $