Perforce Defect Tracking Integration Project
This manual is the Perforce Defect Tracking Integration 1.0 User's Guide. It teaches the use of the Perforce Defect Tracking Integration; detailed instructions on using Perforce and your defect tracker aren't given here. If you need more information on using Perforce, please see the Perforce Command Line User's Guide, the Perforce Command Reference, or the Perforce on-line help system. If you need more information on using your defect tracking system, please see the manuals for the system or consult your defect tracking administrator.
If you're administering the Perforce Defect Tracking Integration (P4DTI), you'll need our Perforce Defect Tracking Integration Administrator's Guide. If you're installing the P4DTI, the Administrator's Guide is the place to start.
The P4DTI makes the defect tracker's records appear as jobs in Perforce. You can work with jobs more or less just as described in the Perforce manuals, and your changes are reflected in the defect tracker. This saves you having to switch between Perforce and the defect tracker to do your work. For information on how to work with jobs in Perforce, see the Perforce Command Line User's Guide.
Perforce has a mechanism for linking changelists to jobs. The P4DTI links the changelists to defect tracker issues as well, so you don't need to switch to the defect tracker and copy out information about your changes. Linking also allows you to:
The P4DTI makes the links to changelists appear in the defect tracker, making it easy to see what was done or is currently being done to resolve a defect.
See the Perforce Defect Tracking Integration Administrator's Guide for an overview of how the P4DTI works.
A typical organization might use the P4DTI in the following way:
For information about your organization's workflow policy, or how you should use the P4DTI, consult your manager or the P4DTI administrator.
The P4DTI has the following restrictions:
Create issues in the defect tracker as normal. Each organization has its own policies for how to create issues, so if you need instructions, consult your defect tracker administrator.
You can't create issues by creating jobs in Perforce.
You can use the defect tracker to see a list of issues assigned to you in the normal way. In addition, your defect tracker might be configured to send you e-mail messages when issues are assigned to you.
You can also use Perforce to see the issues assigned to you, as described in the following subsections. Each issue is represented by a Perforce job, and you can use the Perforce job commands. Each job has a field containing the name of the user to whom it is assigned, and another containing its status. The exact name of these fields depends on which defect tracker you're using and how the P4DTI has been configured for your organization. Ask your P4DTI administrator if you're not certain which field to use. This section assumes that the user field is called "owner", the status field is called "state", and the "state" field is set to "assigned" when an issue is assigned for development.
Perforce 2000.2 does not provide a way of viewing the list of jobs assigned to you from the Web GUI (P4Web) or any of the development environment plug-ins.
To find issues assigned to you, follow these steps:
You might also find it useful to click the job status column heading to sort the jobs by their status, or to enter a jobview like "owner=spqr state=assigned" to restrict the view further.
To find issues assigned to you, enter a p4 jobs
command. For example, the following command displays a list of jobs that belong to the user whose Perforce userid is "spqr":
p4 jobs -e "owner=spqr"
The following command further limits the output to jobs that have been assigned to that user:
p4 jobs -e "owner=spqr state=assigned"
You can edit an issue by editing the contents of the job in Perforce. Your changes are replicated back to the defect tracker. This procedure is useful when you want to:
If you change the issue in a way that the defect tracker doesn't allow--for example, if your action causes an error, or if it's forbidden by the defect tracker workflow--then the replicator undoes the change in Perforce when it next wakes up, and sends you an e-mail message explaining what happened. The e-mail message contains your changes, so you won't have lost them.
To change an issue, edit the job in Perforce as described in the following subsections. Depending on your organization's policies, you might need to add some text explaining why you've edited the job. (If you have made changes and have already submitted them, you need to link them to the job using the method described in Section 9, "Linking already-completed work to an issue".)
Perforce 2000.2 does not provide a way of editing an issue from the Web GUI (P4Web) or any of the development environment plug-ins.
To edit an issue, follow these steps:
Figure 2. Editing a job using the Perforce Windows GUI
To edit an issue from the Perforce command line, enter a p4 job
command and edit the job appropriately. For example, the following command opens a form in your editor that allows you to edit the job BUG00094:
p4 job BUG00094
For more information, see the Perforce Command Line User's Guide.
The P4DTI allows you to link your work in progress to an issue. This link records your intentions and so has several advantages:
To gain these advantages, you first need to set up a user jobview as described in Section 6.1, and then create a pending changelist containing your edits and link it to a Perforce job, as described in Section 6.2 (for the Perforce Windows GUI) or Section 6.3 (for the Perforce command line). The link will show up in the defect tracker. For more information, see the Perforce Command Line User's Guide.
Note that you can only ever link a changelist with an issue once. If you link it with the same issue again using a different keyword, the effect is just to change the keyword.
Perforce 2000.2 has no way of handling numbered pending changelists from the Web GUI (P4Web) or any of the development environment plug-ins, so this method is not available from those interfaces.
To set your user jobview in the Perforce Windows GUI, follow these steps:
To set your user jobview from the Perforce command line, follow these steps:
p4 user
. To start work and link it to an issue, follow these steps:
You can also add more links to jobs by selecting the changelist, choosing Changelist > Edit Spec, and repeating the steps above.
To add more links and set the status of the jobs to "closed", follow these steps:
Note that the list of jobs in this dialog is not related to your user jobview. It's the same list as in the Perforce Jobs pane. (See Figure 1 for an example of the Perforce Jobs pane).
To add more edits to the changelist later, drag the edits from other changelists.
To check out files for edit, drag them from the depot view.
To delete links to jobs, select the link inside the changelist and choose Changelist > Remove Job Fix.
Figure 3. Creating a new changelist and linking it to jobs
To start work and link it to an issue, follow these steps:
p4 change -s
This command opens a change specification in your editor. With the "-s" option, a list of jobs that match your jobview appears in the text form (see Figure 4).
When you submit a pending changelist later, the status of the linked jobs changes as specified. (To submit a pending changelist, use a command like p4 submit -c changelist
).
You can also add more links to jobs by using the following command:
p4 change changelist
where changelist is the number of the changelist you created above.
To link pending changelists with jobs, use a command like the following:
p4 fix -s resolved -c 3004 ENH00034 BUG00094
(where "resolved" is the status you want the jobs to change to, "3004" is the pending changelist number, and "ENH00034" and "BUG00094" are the jobs you want to link the changelist with).
To add more edits to the changelist later, use the -c
option to many Perforce commands, or move the edits from other changelists using the p4 reopen -c
command. For more information, see the Perforce Command Line User's Guide.
To remove links, use a command like the following:
p4 fix -d -c 3004 ENH00034 BUG00094
(where "resolved" is the status you want the jobs to change to, "3004" is the pending changelist number, and "ENH00034" and "BUG00094" are the jobs you want to remove the link from).
Figure 4. Selecting jobs to link when submitting or creating a change from the command line with a jobview set
# A Perforce Change Specification.... Change: new Client: newton-skylark User: newton Status: new Description: <enter description here> Jobs: BUG00003 ignore # When -O3 is specified, some loo BUG00001 ignore # The division operator gets its BUG00002 ignore # There's no delete command Files: //depot/project/editor/src/buffer.c # edit //depot/project/editor/src/buffer.h # edit |
You can submit a change and link it to an issue without changing the issue status. This procedure allows an organization to track partially completed work that's related to an issue, as well as the final submission that resolves it.
Note: Your organization's policy regarding links between changes and issues might not allow you to use this feature. For more information, consult your manager or P4DTI administrator.
If you're linking intermediate stages of changelists with issues, you probably don't want to change the status of the issue. The way to do this is to link the changelist with the issue as usual, but with the same status as the issue currently has. For example, in Perforce you can use the p4 fix
command with the "-s" argument set to the current status of that issue. When linking the final check-in, the "-s" argument is something like "fixed" or "resolved" or perhaps "closed".
To submit partial work while keeping issues, follow the procedures described in Section 8, except that, when fixing the job, set the status to the job's current status, rather than to the resolved status.
Once you have completed work on a job, you can use Perforce to submit the associated changelist, link the changelist to the job, and change the job status, all at the same time.
Make sure your jobview is set before you follow the procedures in this section. See Section 6.1, "Setting your user jobview".
Perforce 2000.2 has no way of linking submitted changelists with jobs from the Web GUI (P4Web).
To submit completed work and resolve issues, follow these steps:
Figure 5. Selecting jobs to link when submitting from the Perforce Windows GUI with a jobview set
If the edits you want to link are on your default changelist, follow these steps to submit completed work and resolve issues:
p4 submit -s
This command opens a change specification in your editor. With the "-s" option, a list of jobs that match your jobview appears in the text form. (See Figure 4 for an example.)
If the edits you want to link are on a pending changelist, follow these steps:
Submit the changelist by entering the command
p4 submit -c changelist
To submit completed work and resolve issues, follow these steps:
When you submit your changelist, the status of the jobs you left in the form is updated to match the JobStatus field and the changelist is linked with them with that status.
Figure 6. Selecting jobs to link when submitting from Visual Studio
You can use Perforce to link a change that you've already made with a issue you've been assigned. For example, suppose you realize that a change you made yesterday also resolves some issues you've been assigned to work on today. You can record this information in the defect tracking system and get rid of those issues.
Note: The defect tracker's workflow might prevent you from linking to an issue that you don't own. If you try, the P4DTI removes your link and sends you e-mail.
Perforce 2000.2 does not provide a way of linking submitted changelists with jobs from the Web GUI (P4Web) or any of the development environment plug-ins.
To link already-completed work to an issue, follow these steps:
To link already-completed work to an issue from the Perforce command line, enter a p4 fix
command. For example, the following command links changelist 4096 with issues ENH00023 and BUG001239 and changes their status to "resolved":
p4 fix -s resolved -c 4096 ENH00023 BUG001239
If you don't specify a "-s" option, the issue status is changed to "closed".
You can use Perforce or the defect tracker to see the changes resulting from an issue, as described in the following subsections. This procedure is useful if you need to:
Perforce 2000.2 does not provide a way of finding the changes resulting from an issue from the Windows GUI, the Web GUI (P4Web), or any of the development environment plug-ins.
To find the changes linked to an issue, follow these steps:
Figure 9. Finding linked changes from the Perforce Windows GUI
To find the changes linked with an issue, enter a p4 fixes
command. For example, the following command lists the changes resulting from issue ENH00034:
p4 fixes -j ENH00034
For details, see the Perforce Command Line User's Guide.
In TeamTrack, look in the Version Control section of the case form to find the changes linked with an issue (see Figure 10). If you don't see the Version Control section, follow these steps to display it:
Figure 10. The changes linked with a TeamTrack case
You can use Perforce to see the issues linked with a changelist.
Perforce 2000.2 does not provide a way of finding the issues linked with a changelist from the Web GUI (P4Web) or any of the development environment plug-ins.
To find the issues linked with a change, follow these steps:
Figure 11. Finding linked issues from the Perforce Windows GUI
To find the issues linked with a change, enter a p4 fixes
command. For example, the following command finds the issues linked with changelist 4339:
p4 fixes -c 4339
For details, see the Perforce Command Line User's Guide.
You can use Perforce to find out which files were changed in order to fix an issue. To do this, you first need to find out the changelists linked with the issue, as described in Section 11, "Finding the issues linked with a change".
Perforce 2000.2 does not provide a way of finding files that were checked in for an issue from the Web GUI (P4Web), or any of the development environment plug-ins.
To find the files affected by an issue, follow these steps:
To find the files affected by an issue, follow these steps:
Enter a p4 describe
command at the Perforce command line. For example, the following command outputs a list of the files that were checked in to fix the issue and the diffs for those files:
p4 describe 4339
For more information, see the Perforce Command Line User's Guide.
You can use the Perforce command line to find the issues linked with particular files. This procedure is very useful for finding out which issues have affected files in the past.
To find out how a file has been affected by an issue, enter a p4 fixes
or a p4 jobs
command at the Perforce command line. For example, the following command lists the links and changelists for the files with a ".c" extension in the "/depot/foo/bar" directory:
p4 fixes //depot/foo/bar/*.c
The following command lists all the issues that have been linked to all the files with a ".c" extension in the "/depot/foo/bar" directory:
p4 jobs //depot/foo/bar/*.c
For more information, see the Perforce Command Line User's Guide.
Perforce 2000.2 does not provide a way of finding issues linked with files from the Windows GUI, the Web GUI (P4Web), or any of the development environment plug-ins.
If you've been linking your work with issues as described in Section 6, you can find out which issues you're working on. This procedure is useful when, for example, you are resuming work on a project after a few days away and can't quite remember which issues you were last working on.
To find who's working on an issue, or issues you were working on in a different workspace, see Section 15, "Finding out where an issue is being worked on and by whom".)
Perforce 2000.2 does not provide a way of finding issues being worked on in a particular workspace from the Web GUI (P4Web) or any of the development environment plug-ins.
To find the issues you're working on, follow these steps:
To find out what you were working on, use a combination of the p4 changes
and p4 fixes
commands. For example, the following command finds your pending changelists:
p4 changes -s pending | grep username
The following command then shows the issues you were working on in that changelist:
p4 fixes -c changelist
If other people at your organization are linking their work with issues as described in Section 6, you can find out who's working on an issue and in which workspace. This procedure is useful when you know that someone is working on an issue but you don't know who or where their work is--they might be on vacation, or have left the company, or perhaps it's you and you've just forgotten all about it.
To find out which issues you were working on in a particular workspace, see Section 14, "Finding the issues you're working on".
Perforce 2000.2 does not provide a way of finding the workspace in which a issue is being worked on from the Web GUI (P4Web) or any of the development environment plug-ins.
To find out where an issue is being worked on, follow these steps:
To find out where an issue is being worked on, use a combination of the p4 fixes
and p4 changes
commands. For example, the following commands list the changelists that are linked to BUG0743 and the list of pending changelists:
p4 fixes -j BUG0743
p4 changes -s pending
Any changelists that appear in both lists are work in progress, and this tells you the user and client (workspace) where the work is happening.
[GDR 2000-05-03] | "Requirements and Use Cases for Perforce/Defect Tracking Integration"; Gareth Rees; Ravenbrook Limited; 2000-05-03. |
[Perforce 2000-12-22a] | "Perforce 2000.2 P4 Command Line User's Guide"; Perforce Software; 2000-12-22; <http://www.perforce.com/ perforce/doc.002/ manuals/p4guide/>, <ftp://ftp.perforce.com/ /pub/perforce/r00.2/doc/ manuals/p4guide/p4guide.pdf>. |
[Perforce 2000-12-22b] | "Perforce 2000.2 System Administrator's Guide"; Perforce Software; 2000-12-22; <http://www.perforce.com/ perforce/doc.002/ manuals/p4sag/>, <ftp://ftp.perforce.com/ /pub/perforce/ r00.2/doc/ manuals/p4sag/p4sag.pdf>. |
2000-08-10 | RB | Created placeholder. |
2000-10-15 | LMB | Added section titles; copied in some use cases as comments. |
2000-11-10 | RB | Added scads of text with rough documentation of many of the use cases so that LMB can work on real documentation. |
2000-11-26 | LMB | Fixed Sections 4.5 and 4.6. Started writing Section 4.15. Started writing Section 2. |
2000-11-26 | RB | Changed "document" to "file" throughout. |
2000-11-30 | RB | Updated references to Perforce 2000.1 to 2000.2, now that the AG says to use 2000.2 |
2000-12-04 | RB | Added screenshots and text figures at various places suggested by LMB. |
2000-12-05 | RB | Added brief instructions for using the new Show Fixes button in the Perforce Windows GUI. |
2000-12-06 | RB | Corrected the instructions for "p4 submit" to "p4 submit -s" and removed unnecessary figures for the previously different "p4 change -s". |
2000-12-06 | RB | Added overview sections. |
2000-12-06 | RB | Complete re-organization of the manual into more logical steps. |
2000-12-07 | RB | Added table of contents. Renumbered figures. |
2000-12-07 | RB | Removed note about the "ignore" bug in "p4 submit -s" and "p4 change -s" as it's now fixed in the Perforce server level we require. |
2001-01-02 | GDR | Section 5.1 suggests jobviews that will work in both the TeamTrack and Bugzilla integrations. Made reference style consistent with AG. Added section 2.5 asking readers to upgrade to 2000.2. |
2001-01-05 | LMB | Made lots of copyedits. Removed ellipses, since they don't conform to Perforce style. Added glossary entries. |
2001-01-07 | LMB | Finished improving as per my intuition. Incorporated some comments from TC@perforce (most weren't applicable to the UG). Finished the glossary. |
2001-01-08 | LMB | Deleted comments, title material, and Sections A and B in preparation for handoff to Perforce. |
2001-01-21 | LMB | At GDR's request, replaced title material and Sections A and B. |
2001-01-22 | LMB | As per TC@perforce's request: started every numbered step with a concrete verb; commented out Section 2.1 and Figures 3 and 4; renumbered figures; renamed Section 2.3; added necessary verbiage to all procedure lead-ins. Re-read TC@perforce's requests more carefully; put Section 2.1 back, moved Section 3 to Section 2.2, and renumbered all headings. At Richard's request, re-added Figure 4 and renumbered figures. |
2001-02-01 | RB | Rewrote introduction to section 2 to provide description of the requirements the software meets without sounding like "marketing". Updated references to Perforce manuals to version 2000.2. |
2001-03-02 | RB | Transferred copyright to Perforce under their license. |
changelist | An atomic change transaction in Perforce. | |
DT | Defect Tracker, Defect Tracking System | Examples are TeamShare's TeamTrack, Soffront TRACK Defects, Bugzilla |
fix | A job that has been linked to a changelist. | |
issue | A user-defined unit of work tracked by the defect tracker. | |
job | A user-defined unit of work tracked by Perforce. | |
jobview | A string used to find jobs that match particular criteria. | |
pending changelist | A changelist that has not been submitted. | |
P4 | The Perforce SCM Software | Perforce Software's fast configuration management system software. We do not use the term P4 to refer to Perforce Software, the company. |
P4DTI | Perforce Defect Tracking Integration | The software that integrates Perforce Software's fast configuration management system (P4) to defect tracking systems. |
replication | The operation of copying data between a defect tracker and a Perforce server in order to keep each one up to date with changes made in the other. Replication allows developers to do their routine defect resolution work entirely from their Perforce client, without needing to use the defect tracker's interface. It also allows developers to relate their changes to defect tracking issues. | |
replicator | A process that copies (replicates) data between a defect tracker and a Perforce server in order to keep each one up to date with changes made in the other. | |
workflow | A set of rules that control who can do what to which issues. |
This document is copyright © 2001 Perforce Software, Inc. All rights reserved.
Redistribution and use of this document in any form, with or without modification, is permitted provided that redistributions of this document retain the above copyright notice, this condition and the following disclaimer.
This document is provided by the copyright holders and contributors "as is" and any express or implied warranties, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event shall the copyright holders and contributors be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement of substitute goods or services; loss of use, data, or profits; or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of this document, even if advised of the possibility of such damage.