Perforce Helix: Difference between revisions

Perforce
Developer(s)	Perforce Software, Inc.
Initial release	1995
Stable release	2013.3
Type	Revision control
License	Proprietary
Website	www.perforce.com

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 15:31, 26 February 2014

Perforce is a commercial, proprietary revision control system developed by Perforce Software, Inc.

Architecture

The Perforce server manages a central database and a master repository of file versions. Perforce supports both Git clients and clients that use Perforce's own protocol. A Git client can communicate with the Perforce server over SSH, and other Perforce clients communicate with the server via TCP/IP using a proprietary RPC and streaming protocol. Users submit changed files together in changelists, which are applied as Atomic commits.

Server

Metadata

The Perforce database is proprietary, preconfigured, and self-installed. It stores system-related metadata (file state, file attributes, branching and merging history, changelists, change descriptions, users, groups, labels, etc.). Files are identified by namespace (i.e., by OS-neutral filenames). File content itself is not stored in the database. MD5 hashes of file content are stored in the database, however, and can be used to verify repository file integrity.

Database tables are stored as binary files. Checkpoints and journals are written as text files that can be compressed and offloaded. A database that has been corrupted by hardware failure or other catastrophe can be recovered from the most recent journal and checkpoint. Administrators must plan for disaster recovery by configuring database journaling and setting up regular checkpoints.

Depot

Versioned file content is stored in a master directory hierarchy whose top levels are called "depots". Text file revisions are stored as RCS deltas^{[notes 1]} and binary file revisions are stored in their entirety.

The encoding used for text files in the repository is either ASCII or UTF-8,^[1] depending on Perforce server configuration. Repository files are not encrypted. Revisions that are branches or copies of other revisions are virtual copies within the repository. All revisions are preserved by default; limits can be set on the number of revisions preserved. Obsolete revisions and files can be purged by the administrator. Repository files must be included in regular system backups.

Clients

Clients to the Perforce system fall into roughly five categories: Git, command, GUI, web, and plugin. The Perforce system can make part or all of its content available as Git repositories. Users of Git and of other clients can work with the same file content and history. Git commits are visible to users of other clients as Perforce changelists, and vice versa.

The original command interface is P4, the command-line client. P4 can be used in any command shell or script. It produces human-readable output by default, but can also produce tagged text output, marshalled Python output, and marshalled Ruby output. Native C++ and Java APIs to the Perforce client commands are also available, as are Lua, Perl, Python, PHP, Objective-C, and Ruby extensions built upon the C++ API.^[2]

The command interfaces support the system's complete client functionality and can be used with OS-native filename syntax, as well as with Perforce's OS-neutral filename syntax.

Two GUI clients are available for users, the cross-platform, Qt-based P4V, and the Windows-only P4Win (in legacy maintenance mode since 2008^[3]). Both support the majority of end-user operations. An administration GUI client, P4Admin, supports a subset of administrative operations.^[4] P4Admin, like P4V, is cross-platform and Qt-based. P4V and P4Admin can be extended with applets written in JavaScript and HTML.^[5]

Plugins are provided for the Eclipse^[6] and Visual Studio^[7] IDEs.

A web interface is provided by P4Web,^[8] a program that is both a Perforce client and a stand-alone HTTP daemon. P4Web can be run as a shared web server to provide read-only access to the Perforce file repository and metadata. It can also be run on a user's machine, enabling web browsers to become the interface to client operations on the local machine.

The plugin interfaces are behind-the-scenes programs that integrate Perforce client functionality into third-party software. Perforce plugins are available for desktop environments, software development tools, digital asset development tools, software build tools, code review systems, defect tracking systems, office automation tools, SQL clients, and FTP clients.

Distributed and remote revision control

Perforce has four mechanisms for providing revision control to distributed or remote teams; these mechanisms can be used independently or in combination. The first is a proxy server that caches frequently read versions in order to reduce file access times for remote users. This mechanism accommodates closed development organizations where a centrally controlled file repository and a universally accessible database are desired.

The second mechanism, known as remote depots, lets users connected to one server access file versions managed by other servers. With remote depots, each organization has control of its own server and makes parts or all of its repository visible to other servers. This mechanism is used for loosely coupled development organizations where a peer-to-peer approach is desired.

The third mechanism, known as replication,^[9] mirrors all (or some) of the repository data to another server. Replicas provide faster response time for remote users.

Finally, Perforce can be replicated to Git repositories, using the standard Git protocol and commands.

Features

Complete file and metadata history
Full revision history for branched, renamed, moved, copied, and deleted files
Three-way text file merging; merge tracking and re-merge prevention; common ancestor detection
Graphical diffing, merging, and offline/online reconciliation tools
Graphical file content history and branch history viewers
Graphical administrative interface
Image thumbnails
Centralized, access-controlled repository with support for distributed revision control (see below)
Changelists – changed files can be grouped together and tracked as logical changes^{[notes 2]}
Atomic commits – the server assures that changelists are committed in their entirety
Shelving – users can save and restore work in progress for code reviews or task switching
Support for ASCII, Unicode, binary, symbolic link (on Unix), Mac-specific, and UTF-16 files
Support for internationalization and localization
Support for RCS-style keyword expansion
File compression for repository storage and network transfer
Multi-platform, cross-platform – a single Unix or Windows server can support clients on any OS
Server-side event triggers
Programmable command-line client and API
SDK for integrating with external systems (e.g., defect tracking)
Change notification by RSS; support for email change notifications
Replication of files and metadata^[10] to support backup and performance improvement
Broker for implementing local policies, restricting available commands, or redirecting commands to alternative servers^[11]
Archiving files to reclaim server disk space^[12]
Encrypted SSL connections from clients to server^[13]

Concurrency model

The Perforce system offers a hybrid of merge and lock concurrency models.^{[notes 3]} As with similar systems, users do not have to lock files in order to work on them and are required to resolve concurrent, committed changes before submitting their work. Users may optionally lock files to ensure that they won't have to resolve concurrent changes.

However, the Perforce model is slightly different from those of similar systems in that users are expected to let the system know in advance which files they intend to change, even if they don't mean to lock them. Giving advance notice puts files in a pending changelist that can be submitted to the server. It also enables the system to alert other users working on the same files. Thus users can tell when they are working in parallel and can take the opportunity to coordinate with one another before making changes that could otherwise be difficult to merge.

Perforce enforces this advanced notification requirement loosely by setting read-only permission on workspace files as it fetches them from the repository. Users can bypass the requirement, by choice or by necessity (when working offline, for example), simply by hijacking file permissions and modifying files as they see fit. It is up to the user, in these cases, to remember to use Perforce to reconcile offline work and put hijacked files in a pending changelist so they can be submitted. (It is also up to users to leave hijacked files writable after changing them. A read-only file that is not in a pending changelist is assumed by Perforce to be a candidate for update by replacement.)

Branching and merging

A file is uniquely identified by its complete filename, e.g., //depot/trunk/src/item.cpp. Any non-deleted revision of a file can be branched. Perforce uses inter-file branching,^[14] wherein branching creates a new file with a new name. For example, my/index.php may be branched into your/index.php and each file may then evolve independently. Repository paths are typically designated as containers for branched sets of files. For example, files in the //depot/trunk path may be branched as a set into a new //depot/rel1.0 path, resulting in two sets of files evolving independently and between which changes can be merged.

In Perforce, the operation that merges changes from one branch to another is called integration. Integration propagates changes from a set of donor files into a set of corresponding target files; optional branch views can store customized donor–target mappings. By default, integration propagates all outstanding donor changes. Donor changes can be limited or cherry-picked by changelist, date, label, filename, or filename pattern-matching. The system records all integrations, uses them to select common ancestors for file merging, and does not by default perform redundant or unnecessary integrations.

Merging is actually only one of three possible outcomes of an integration. The others are ignoring (aka "blocking") and copying (aka "promoting"). Merging is used to keep one set of files up to date with another. For example, a development branch may be kept up to date with its trunk through repeated merging. Ignoring disqualifies changes in one set of files from future integration into another. It is often used when a development branch must be up to date with, and yet divergent from, its trunk. Copying is typically used to promote the content of an up-to-date development branch into a trunk.

Branching also supports renamed and moved files. The 'move' command branches originals to new files and deletes the originals. A branched file is no different from an added file; branched files are peers, not offshoots, of their originals. The system keeps track of file origins, however, and refers to them when displaying the history of renamed files.

Perforce streams^[15] offer a way to capture more information about a branch, including ancestry and included paths. This information is used to provide guidelines for branching and merging operations.

Access control and security

The Perforce server stores file content in a master repository that, when properly installed, is inaccessible to users. User access to files is controlled by one or more Perforce superusers. A range of file access protection levels can be granted. Protections can be set for repository file paths, users, groups, and IP address subnets. The server can maintain an audit log of client access events for SOX and other compliance requirements.

User authentication is controlled by the Perforce system administrator. Password strength is configurable; ticket-based authentication can be configured as well. Triggers (custom scripts or programs that run at predefined events) can be set on many but not all Perforce user commands and used to extend user authentication (with LDAP or SSO, for example), to block or allow user commands, and to constrain or normalize file modifications. Triggers are run by the Perforce server and do not have access to client machines or workspaces.

Perforce, like most version control systems, does not encrypt file content in the master repository or on user machines.^[16]^[17]^[18] Perforce versions prior to 2012.1 cannot encrypt file content sent over the network. A tunneling protocol (like VPN or SSH) must be used to secure network transfers with those versions.^[19]

The Perforce client completely trusts the server, including writing arbitrary files anywhere in the local filesystem, and therefore running arbitrary code from the server.^[20] That means the server has complete control over the client user's account, including reading and writing and sending all non-source code files of the user. In environments where the Perforce server is managed by a third party, this poses a significant threat to the client's security and privacy.

Availability

Use of the Perforce server is unrestricted and free for up to 20 users, 20 workspaces and unlimited files, or unlimited users and up to 1,000 files, without a license. A license must be purchased for more users or workspaces; licenses may be purchased in perpetuity or on a subscription basis. The Perforce versioning engine, clients, plugin software, tools, and APIs are also freely available.^[21]

Free licenses are available for open-source software development, school or classroom projects, and trial/evaluation periods. Use of the Perforce client and plugin software is unrestricted, as is online access to Perforce technical documentation.^[22]

The server and client software are released as pre-built executables for Microsoft Windows, Mac OS X, Linux, Solaris, FreeBSD, and other operating systems.

Notes

^ Although text file revisions are stored as RCS deltas in the repository, Perforce does not use the RCS system to manage files.
^ Perforce changelists are similar to what other revision control systems refer to as changesets.
^ Comparison of revision control software describes concurrency models in these terms.

References

^ Internationalization Notes for P4D, the Perforce Server, and Perforce client applications. Version 2011.1
^ Perforce Related Software
^ [1]
^ P4Admin - Perforce Administration Tool
^ Perforce JavaScript API
^ P4Eclipse
^ P4VS
^ P4Web User Guide
^ Perforce Server
^ Perforce Replication
^ The Perforce Broker
^ Reclaiming disk space by archiving files
^ Secure Perforce communications with SSL
^ Christopher Seiwald (1996). "Inter-File Branching: A Practical Method for Representing Variants". In Software Configuration Management: ICSE '96 SCM-6 Workshop, Berlin, Germany, ed. Ian Sommerville, Springer, ISBN 3-540-61964-X.
^ Perforce Streams
^ Protecting Your Critical Assets, Lessons Learned from “Operation Aurora”, By McAfee Labs and McAfee Foundstone Professional Services
^ 'Google' Hackers Had Ability to Alter Source Code
^ Perforce Software Responds to McAfee White Paper on Operation Aurora
^ Perforce Knowledge Base: Securing Your Perforce Server
^ Client security hole alert, By Ben Bucksch Full-Disclosure post
^ Perforce 20/20 for Free
^ Perforce Licensing and Pricing

External links

Wingerd, Laura (November 18, 2005). Practical Perforce. O'Reilly Media, Inc. ISBN 978-0-596-10185-5. {{cite book}}: Invalid |ref=harv (help)

[1] Although text file revisions are stored as RCS deltas in the repository, Perforce does not use the RCS system to manage files.

[11] Perforce changelists are similar to what other revision control systems refer to as changesets.

[16] Comparison of revision control software describes concurrency models in these terms.

[2] Internationalization Notes for P4D, the Perforce Server, and Perforce client applications. Version 2011.1

[3] Perforce Related Software

[4] [1]

[5] P4Admin - Perforce Administration Tool

[6] Perforce JavaScript API

[7] P4Eclipse

[8] P4VS

[9] P4Web User Guide

[10] Perforce Server

[12] Perforce Replication

[13] The Perforce Broker

[14] Reclaiming disk space by archiving files

[15] Secure Perforce communications with SSL

[17] Christopher Seiwald (1996). "Inter-File Branching: A Practical Method for Representing Variants". In Software Configuration Management: ICSE '96 SCM-6 Workshop, Berlin, Germany, ed. Ian Sommerville, Springer, ISBN 3-540-61964-X.

[18] Perforce Streams

[19] Protecting Your Critical Assets, Lessons Learned from “Operation Aurora”, By McAfee Labs and McAfee Foundstone Professional Services

[20] 'Google' Hackers Had Ability to Alter Source Code

[21] Perforce Software Responds to McAfee White Paper on Operation Aurora

[22] Perforce Knowledge Base: Securing Your Perforce Server

[23] Client security hole alert, By Ben Bucksch Full-Disclosure post

[24] Perforce 20/20 for Free

[25] Perforce Licensing and Pricing

[notes 1]

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[notes 2]

[10]

[11]

[12]

[13]

[notes 3]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

@@ Line 29: / Line 29: @@
 ==Architecture==
 The Perforce server manages a central [[database]] and a master [[wikt:repository|repository]] of [[Computer file|file]] versions.
-Perforce supports both [[Git (software)|Git]] clients and clients that use Perforce's own protocol. A Git client can communicate with the Perforce server over [[Secure_Shell|SSH]], and other Perforce clients communicate with the  [[Server (computing)|server]]  via [[TCP/IP]] using
+Perforce supports both [[Git (software)|Git]] clients and clients that use Perforce's own protocol. A Git client can communicate with the Perforce server over [[Secure_Shell|SSH]], and other Perforce clients communicate with the  [[Server (computing)|server]]  via [[TCP/IP]] using a proprietary [[Remote Procedure Call|RPC]] and [[stream (computing)|streaming]] protocol.  Users submit changed files together in [[Source Code Management#Common vocabulary|changelists]], which are applied as [[Atomic commit]]s.
-a proprietary [[Remote Procedure Call|RPC]] and [[stream (computing)|streaming]] protocol.  Users submit changed files together in [[Source Code Management#Common vocabulary|changelists]], which are applied as [[Atomic commit]]s.
 ===Server===
 ====Metadata====
+The Perforce database is proprietary, preconfigured, and self-installed. It stores system-related [[metadata]] (file state, file attributes, branching and merging history, changelists, change descriptions, users, groups, labels, etc.). Files are identified by namespace (i.e., by OS-neutral filenames). File content itself is not stored in the database. [[MD5]] hashes of file content are stored in the database, however, and can be used to verify repository file integrity.
-The Perforce database is proprietary, preconfigured, and self-installed.
-It stores system-related [[metadata]]
-(file state, file attributes, branching and merging history,
-changelists, change descriptions, users, groups, labels, etc.).
-Files are identified by namespace (i.e., by OS-neutral filenames).
-File content itself is not stored in the database.
-[[MD5]] hashes of file content are stored in the database,
-however, and can be used to verify repository file integrity.
+Database tables are stored as binary files. [[Transaction checkpoint|Checkpoints and journals]] are written as text files that can be compressed and offloaded. A database that has been corrupted by hardware failure or other catastrophe can be recovered from the most recent journal and checkpoint. Administrators must plan for disaster recovery by configuring database
-Database tables are stored as binary files.
-[[Transaction checkpoint|Checkpoints and journals]] are written as text files
-that can be compressed and offloaded.
-A database that has been corrupted by hardware failure or other catastrophe
-can be recovered from the most recent journal and checkpoint.
-Administrators must plan for disaster recovery by configuring database
 journaling and setting up regular checkpoints.
@@ Line 61: / Line 48: @@
 ===Clients===
 Clients to the Perforce system fall into roughly five categories: [[Git (software)|Git]],
 [[command (computing)|command]], [[GUI]],
 [[World Wide Web|web]], and [[Plug-in (computing)|plugin]]. The Perforce system can make part or all of its content available as Git repositories. Users of Git and of other clients can work with the same file content and history.  Git commits are visible to users of other clients as Perforce changelists, and vice versa.
+The original command interface is P4, the [[command line interface|command-line]] client. P4 can be used in any command [[shell (computing)|shell]] or [[scripting language|script]]. It produces [[human-readable]] output by default, but can also produce [[tag (metadata)|tag]]ged text output, marshalled [[Python (programming language)|Python]] output, and marshalled [[Ruby (programming language)|Ruby]] output. Native C++ and Java APIs to the Perforce client commands are also available, as are [[Lua (programming language)|Lua]], [[Perl]], Python, PHP, Objective-C, and Ruby extensions built upon the C++ API.<ref>[http://www.perforce.com/perforce/loadsupp.html Perforce Related Software]</ref>
-The original command interface is P4, the [[command line interface|command-line]] client.
-P4 can be used in any command [[shell (computing)|shell]] or [[scripting language|script]].
-It produces [[human-readable]] output by default, but can also produce [[tag (metadata)|tag]]ged text output, marshalled [[Python (programming language)|Python]] output, and marshalled [[Ruby (programming language)|Ruby]] output.
-Native C++ and Java APIs to the Perforce client commands are also available,
-as are [[Lua (programming language)|Lua]], [[Perl]], Python, PHP, Objective-C, and Ruby extensions built upon the C++ API.<ref>[http://www.perforce.com/perforce/loadsupp.html Perforce Related Software]</ref>
-The command interfaces support the system's complete client functionality and
-can be used with OS-native [[filename]] syntax, as well as with Perforce's OS-neutral filename syntax.
+The command interfaces support the system's complete client functionality and can be used with OS-native [[filename]] syntax, as well as with Perforce's OS-neutral filename syntax.
-Two GUI clients are available for users,
-the [[cross-platform]], [[Qt (toolkit)|Qt]]-based P4V,
+Two GUI clients are available for users, the [[cross-platform]], [[Qt (toolkit)|Qt]]-based P4V,
-and the [[Microsoft Windows|Windows]]-only P4Win (in legacy maintenance mode since 2008<ref>[http://www.perforce.com/downloads/legacy-software]</ref>).
+and the [[Microsoft Windows|Windows]]-only P4Win (in legacy maintenance mode since 2008<ref>[http://www.perforce.com/downloads/legacy-software]</ref>). Both support the majority of end-user operations. An administration GUI client, P4Admin, supports a subset of administrative operations.<ref>[http://www.perforce.com/perforce/products/p4admin.html P4Admin - Perforce Administration Tool]</ref>  P4Admin, like P4V, is [[cross-platform]] and [[Qt (toolkit)|Qt]]-based.  P4V and P4Admin can be extended with applets written in JavaScript and HTML.<ref>[http://www.perforce.com/perforce/doc.current/manuals/p4jsapi/index.html Perforce JavaScript API]</ref>
-Both support the majority of end-user operations.
-An administration GUI client, P4Admin, supports a subset of administrative operations.<ref>[http://www.perforce.com/perforce/products/p4admin.html P4Admin - Perforce Administration Tool]</ref>  P4Admin, like P4V, is [[cross-platform]] and [[Qt (toolkit)|Qt]]-based.  P4V and P4Admin can be extended with applets written in JavaScript and HTML.<ref>[http://www.perforce.com/perforce/doc.current/manuals/p4jsapi/index.html Perforce JavaScript API]</ref>
 Plugins are provided for the Eclipse<ref>[http://www.perforce.com/product/components/eclipse_plugin P4Eclipse]</ref> and Visual Studio<ref>[http://www.perforce.com/product/components/visual_studio_plugin P4VS]</ref> IDEs.
-A web interface is provided by P4Web,<ref>[http://www.perforce.com/perforce/doc.current/manuals/p4web/help/index.html P4Web User Guide]</ref>
+A web interface is provided by P4Web,<ref>[http://www.perforce.com/perforce/doc.current/manuals/p4web/help/index.html P4Web User Guide]</ref> a program that is both a Perforce client and a stand-alone [[HTTP]] [[daemon (computer software)|daemon]]. P4Web can be run as a shared [[web server]] to provide read-only access to the Perforce file repository and metadata. It can also be run on a user's machine, enabling [[web browser]]s to become the interface to client operations on the local machine.
-a program that is both a Perforce client and
-a stand-alone [[HTTP]] [[daemon (computer software)|daemon]].
-P4Web can be run as a shared [[web server]] to provide read-only access to
-the Perforce file repository and metadata.
-It can also be run on a user's machine, enabling [[web browser]]s to become
-the interface to client operations on the local machine.
 The plugin interfaces are behind-the-scenes programs that
 integrate Perforce client functionality into third-party software.
 Perforce plugins are available for
-[[desktop environments]], [[software development]] tools,
+[[desktop environments]], [[software development]] tools, [[digital asset]] development tools, [[software build]] tools, [[code review]] systems, [[defect tracking]] systems, [[office automation]] tools, [[SQL]] clients, and [[FTP]] clients.
-[[digital asset]] development tools,
-[[software build]] tools, [[code review]] systems, [[defect tracking]] systems,
-[[office automation]] tools, [[SQL]] clients, and [[FTP]] clients.
 ===Distributed and remote revision control===
-Perforce has four mechanisms for providing revision control to distributed or remote teams;
+Perforce has four mechanisms for providing revision control to distributed or remote teams; these mechanisms can be used independently or in combination. The first is a [[proxy server]] that caches frequently read versions in order to reduce file access times for remote users. This mechanism accommodates closed development organizations where a centrally controlled file repository and a universally accessible database are desired.
-these mechanisms can be used independently or in combination.
-The first is a [[proxy server]] that caches frequently read versions
-in order to reduce file access times for remote users.
-This mechanism accommodates closed development organizations
-where a centrally controlled file repository and a universally accessible database are desired.
+The second mechanism, known as ''remote depots'', lets users connected to one server access file versions managed by other servers. With remote depots, each organization has control of its own server and makes parts or all of its repository visible to other servers. This mechanism is used for loosely coupled development organizations where a [[peer-to-peer]] approach is desired.
-The second mechanism, known as ''remote depots'', lets users
-connected to one server access file versions managed by other servers.
-With remote depots, each organization has control of its own server
-and makes parts or all of its repository visible to other servers.
-This mechanism is used for loosely coupled development organizations
-where a [[peer-to-peer]] approach is desired.
 The third mechanism, known as ''replication'',<ref>[http://www.perforce.com/product/components/perforce_server Perforce Server]</ref> mirrors all (or some) of the repository data to another server.  Replicas provide faster response time for remote users.
@@ Line 148: / Line 109: @@
 Perforce enforces this advanced notification requirement loosely by setting read-only permission on workspace files as it fetches them from the repository. Users can bypass the requirement, by choice or by necessity (when working offline, for example), simply by hijacking file permissions and modifying files as they see fit. It is up to the user, in these cases, to remember to use Perforce to reconcile offline work and put hijacked files in a pending changelist so they can be submitted. (It is also up to users to leave hijacked files writable after changing them. A read-only file that is not in a pending changelist is assumed by Perforce to be a candidate for update by replacement.)
-== Branching and merging ==
+==Branching and merging==
+A file is uniquely identified by its complete filename, e.g., <code>//depot/trunk/src/item.cpp</code>. Any non-deleted revision of a file can be branched. Perforce uses ''inter-file branching'',<ref>Christopher Seiwald (1996). "Inter-File Branching: A Practical Method for Representing Variants". In ''Software Configuration Management: ICSE '96 SCM-6 Workshop, Berlin, Germany'', ed. Ian Sommerville, Springer, ISBN 3-540-61964-X.</ref> wherein branching creates a new file with a new name. For example, <code>my/index.php</code> may be branched into <code>your/index.php</code> and each file may then evolve independently. Repository paths are typically designated as containers for branched sets of files. For example, files in the <code>//depot/trunk</code> path may be branched as a set into a new <code>//depot/rel1.0</code> path, resulting in two sets of files evolving independently and between which changes can be merged.
-A file is uniquely identified by its complete filename, e.g.,
-<code>//depot/trunk/src/item.cpp</code>.
-Any non-deleted revision of a file can be branched.
-Perforce uses ''inter-file branching'',<ref>Christopher Seiwald (1996).
-"Inter-File Branching: A Practical Method for Representing Variants".
-In ''Software Configuration Management: ICSE '96 SCM-6 Workshop, Berlin, Germany'',
-ed. Ian Sommerville, Springer, ISBN 3-540-61964-X.
-</ref> wherein branching creates a new file with a new name.
-For example, <code>my/index.php</code> may be branched into
-<code>your/index.php</code> and each file may then evolve independently.
-Repository paths are typically designated as containers for branched sets of files.
-For example, files in the <code>//depot/trunk</code> path may be branched as a set
-into a new <code>//depot/rel1.0</code> path, resulting in two sets of files
-evolving independently and between which changes can be merged.
+In Perforce, the operation that merges changes from one branch to another is called ''integration''. Integration propagates changes from a set of donor files into a set of corresponding target files; optional ''branch views'' can store customized donor&ndash;target mappings. By default, integration propagates all outstanding donor changes. Donor changes can be limited or cherry-picked by changelist, date, label, filename, or filename pattern-matching. The system records all integrations, uses them to select common ancestors for file merging, and does not by default perform redundant or unnecessary integrations.
-In Perforce, the operation that merges changes from one branch
-to another is called ''integration''.
-Integration propagates changes from a set of donor files into a set of
-corresponding target files;
-optional ''branch views'' can store customized donor&ndash;target mappings.
-By default, integration propagates all outstanding donor changes.
-Donor changes can be limited or cherry-picked by changelist,
-date, label, filename, or filename pattern-matching.
-The system records all integrations, uses them to select common ancestors
-for file merging, and does not by default perform redundant or unnecessary
-integrations.
+Merging is actually only one of three possible outcomes of an integration. The others are ''ignoring'' (aka "blocking") and ''copying'' (aka "promoting"). Merging is used to keep one set of files up to date with another. For example, a development branch may be kept up to date with its trunk through repeated merging. Ignoring disqualifies changes in one set of files from future integration into another. It is often used when a development branch must be up to date with, and yet divergent from, its trunk. Copying is typically used to promote the content of an up-to-date development branch into a trunk.
-Merging is actually only one of three possible outcomes of an integration.
-The others are ''ignoring'' (aka "blocking") and ''copying'' (aka "promoting").
-Merging is used to keep one set of files up to date with another.
-For example, a development branch may be kept up to date with its
-trunk through repeated merging.
-Ignoring disqualifies changes in one set of files from future integration
-into another.
-It is often used when a development branch must be
-up to date with, and yet divergent from, its trunk.
-Copying is typically used to promote the content of an up-to-date
-development branch into a trunk.
+Branching also supports renamed and moved files. The 'move' command branches originals to new files and deletes the originals. A branched file is no different from an added file; branched files are peers, not offshoots, of their originals. The system keeps track of file origins, however, and refers to them when displaying the history of renamed files.
-Branching also supports renamed and moved files.
-The 'move' command branches originals to new files and deletes the originals.
-A branched file is no different from an added file;
-branched files are peers, not offshoots, of their originals.
-The system keeps track of file origins, however,
-and refers to them when displaying the history of renamed files.
 Perforce streams<ref>[http://www.perforce.com/product/product_features/perforce_streams Perforce Streams]</ref> offer a way to capture more information about a branch, including ancestry and included paths.  This information is used to provide guidelines for branching and merging operations.
@@ Line 201: / Line 124: @@
 User access to files is controlled by one or more Perforce [[superuser]]s.
 A range of file access protection levels can be granted.
-Protections can be set for repository file [[Path (computing)|paths]],
+Protections can be set for repository file [[Path (computing)|paths]], [[User (computing)|users]], [[Group (computing)|groups]], and [[IP address]] [[subnetwork|subnets]]. The server can maintain an audit log of client access events for [[Sarbanes-Oxley Act|SOX]] and other compliance requirements.
-[[User (computing)|users]], [[Group (computing)|groups]], and [[IP address]] [[subnetwork|subnets]].
-The server can maintain an audit log of client access events
-for [[Sarbanes-Oxley Act|SOX]] and other compliance requirements.
+User authentication is controlled by the Perforce system administrator. [[Password strength]] is configurable; [[Ticket (IT security)|ticket]]-based authentication can be configured as well. ''Triggers'' (custom scripts or programs that run at predefined events) can be set on many but not all Perforce user commands and used to extend user authentication (with [[LDAP]] or [[Single sign-on|SSO]], for example), to block or allow user commands, and to constrain or normalize file modifications. Triggers are run by the Perforce server and do not have access to client machines or workspaces.
-User authentication is controlled by the Perforce system administrator.
-[[Password strength]] is configurable; [[Ticket (IT security)|ticket]]-based
-authentication can be configured as well.
-''Triggers'' (custom scripts or programs that run at predefined events)
-can be set on many but not all Perforce user commands
-and used to extend user authentication (with [[LDAP]] or [[Single sign-on|SSO]], for example),
-to block or allow user commands, and to constrain or normalize file modifications.
-Triggers are run by the Perforce server and do not have access to client machines or workspaces.
 Perforce, like most version control systems, does not encrypt file content in the master repository or on user machines.<ref>[http://www.wired.com/images_blogs/threatlevel/2010/03/operationaurora_wp_0310_fnl.pdf Protecting Your Critical Assets, Lessons Learned from “Operation Aurora”, By McAfee Labs and McAfee Foundstone Professional Services]</ref><ref>[http://www.wired.com/threatlevel/2010/03/source-code-hacks/ 'Google' Hackers Had Ability to Alter Source Code]</ref><ref>[http://www.perforce.com/perforce/press/pr121_McAfee_statement.pdf Perforce Software Responds to McAfee White Paper on Operation Aurora]</ref>
@@ Line 227: / Line 140: @@
 Free licenses are available for [[open source|open-source]] software development, school or classroom projects, and trial/evaluation periods. Use of the Perforce client and plugin software is unrestricted, as is online access to Perforce technical documentation.<ref>[http://www.perforce.com/purchase Perforce Licensing and Pricing]</ref>
-The server and client software are released as pre-built [[executable]]s for [[Microsoft Windows]],
+The server and client software are released as pre-built [[executable]]s for [[Microsoft Windows]], [[Mac OS X]], [[Linux]], [[Solaris (operating system)|Solaris]], [[FreeBSD]], and other [[operating system]]s.
-[[Mac OS X]], [[Linux]], [[Solaris (operating system)|Solaris]], [[FreeBSD]], and other [[operating system]]s.
 ==See also==
@@ Line 235: / Line 147: @@
 *[[Perforce Jam]]
-== Notes ==
+==Notes==
 {{reflist|group=notes|liststyle=lower-roman}}
-== References ==
+==References==
 {{reflist|colwidth=30em}}
@@ Line 244: / Line 156: @@
 *[http://www.perforce.com/ Perforce Software, Inc. website]
 *[http://www.perforcechronicle.com/ Perforce Chronicle website]
-*[http://www.queryhome.com/32698/p4-perforce-cheat-sheet Commonly Used Commands]
 *{{Cite book
   | last = Wingerd