Perforce 2002.2 User's Guide | ||
<< Previous Chapter About This Manual |
Table of Contents Index Perforce on the Web |
Next Chapter >> Connecting to the Perforce Server |
The Perforce clients can be distributed around a local area network, wide area network, dialup network, or any combination of these topologies. Perforce clients can also reside on the same host as the server.
The following programs do the bulk of Perforce's work:
Files that have been edited within a client workspace are sent to the depot using a changelist, which is a list of files and instructions that tell the depot what to do with those files. For example, one file might have been changed in the client workspace, another added, and another deleted. These file changes can be sent to the depot in a single changelist, which is processed atomically: either all the changes are made to the depot at once, or none of them are. This approach allows users to simultaneously update all files related to a bug fix or a new feature.
Each client workspace has its own client view, which determines which files in the depot can be accessed by that client workspace. One client workspace might be able to access all the files in the depot, while another client workspace might access only a single file. The Perforce Server is responsible for tracking the state of the client workspace; Perforce knows which files a client workspace has, where they are, and which files have write permission turned on.
For basic information about using Perforce, see Chapter 3, Perforce Basics: Quick Start and Chapter 4, Perforce Basics: The Details.
When a file conflict is detected, Perforce allows the user experiencing the conflict to perform a resolve of the conflicting files. The resolve process allows the user to decide what needs to be done: should his file overwrite the other user's? Should his own file be thrown away? Or should the two conflicting files be merged into one? At the user's request, Perforce will perform a three-way merge between the two conflicting files and the single file that both were based on. This process generates a merge file from the conflicting files, which contains all the changes from both conflicting versions. This file can be edited and then submitted to the depot.
To learn how to resolve file conflicts, see Chapter 5, Perforce Basics: Resolving File Conflicts.
For details about labels, see Chapter 8, Labels.
Perforce's Inter-File BranchingTM mechanism allows any set of files to be copied within the depot. By default, the new file set, or codeline, evolves separately from the original files, but changes in either codeline can be propagated to the other.
For details about branching, see Chapter 9, Branching.
Whereas a job represents work that is intended to be performed, a changelist represents work actually done. Perforce's job tracking mechanism allows jobs to be linked to the changelists that implement the work requested by the job. A job can later be looked up to determine if and when it was fixed, what files were modified to implement the fix, who fixed it, and whether the fix has been propagated to other codelines. The fields contained in your system's jobs can be defined by the Perforce system administrator.
Perforce's job tracking mechanism does not implement all the functionality that is normally supplied by full-scale defect tracking systems. Its simple functionality can be used as is, or it can be integrated with third-party job tracking systems through P4DTI - Perforce Defect Tracking and Integration.
To read more about jobs, please see Chapter 10, Job Tracking.
Perforce can be made to run external scripts whenever changelists are submitted. These scripts, called triggers, allow changelists to be validated before they're submitted to the depot.
To learn how to set up the change review daemon, integrate Perforce with third-party defect tracking systems, or write your own daemons, consult the Perforce System Administrator's Guide.
Permissions can be granted or denied based on users' usernames and IP addresses, or can be granted or denied to entire groups of users. Because Perforce usernames are easily changed, protections at the user level provide safety, not security. Protections at the IP address level are as secure as the host itself.
We discuss protections in the Perforce System Administrator's Guide.
For more about P4Win, see the product page at:
Perforce offers full support for both parallel and concurrent development environments. In situations where concurrent file check-out is not desirable, Perforce can be configured to restrict this capability to specific file types or file locations (for instance, management of digital assets in environments where concurrent development is not encouraged).
P4WinMerge is a stand-alone Windows application; it does not require a Perforce Server when used by itself. However, when invoked from within a Perforce client program like the Perforce Command-Line Client, P4Win, or P4Web, a Perforce Server is necessary.
For more about P4WinMerge, see:
For more about using third-party merge tools with Perforce, see:
Perforce Defect Tracking Integration (P4DTI) is an open source project specifically designed to integrate Perforce with other defect tracking systems by replicating Perforce jobs and changelist numbers to their equivalents in the other system.
P4DTI connects your defect tracking system to Perforce, so that you don't have to switch between your defect tracker and SCM tool and enter duplicate information about your work. P4DTI also links changes made in Perforce with defect tracker issues, making it easy to find out why a change was made, find the work that was done to resolve an issue, or generate reports relating issues to files or codelines.
Activity in your Perforce depot - enhancements, bug fixes, propagation of changes into release branches, and so forth - can be automatically entered into your defect tracking system by P4DTI. Conversely, issues and status entered into your defect tracking system - bug reports, change orders, work assignments, and so on, can be converted automatically to Perforce metadata for access by Perforce users. With P4DTI, you can integrate Perforce with any third-party defect tracking or process management software.
P4DTI uses Perforce's built-in "jobs" feature to mirror data in defect tracking systems. While Perforce jobs can be used without additional software for straightforward issue tracking, P4DTI lets you take advantage of third-party user interfaces, reporting tools, databases, and workflow rules to manage complex processes.
P4DTI runs on Unix and Windows. It can be used with a Perforce Server on any platform at Release 2000.2 or newer.
For more about using third-party defect tracking systems with Perforce, including a list of defect tracking systems for which P4DTI integrations have already been built, see:
For more about Perforce IDE Plug-ins, see:
Based on P4ODBC, the Perforce ODBC Data Source, P4Report can be used by ODBC-compliant reporting tools including Crystal Reports®, Microsoft® Access® and Excel®. P4Report can also be integrated with some defect tracking systems.
For more about P4Report and P4SQL, see:
Perforce 2002.2 User's Guide | ||
<< Previous Chapter About This Manual |
Table of Contents Index Perforce on the Web |
Next Chapter >> Connecting to the Perforce Server |