Perforce Software Configuration Management System
Manufacturer: Perforce Software, Inc.
Price: $500 US (free for non-commercial use)
Reviewer: Tom Björkholm
Many of us usually talk about “revision control systems” when we actually mean software-configuration management systems. Most of us do have mixed feelings for these systems. We want the benefits they give us: tracing, branches, stepping back to an old version and other such options. However, we do not want to pay the usual price of overhead, complexity and extra work to set up and use the system. What we really want is a fast, easy-to-understand system that gives us all the benefits without any of the grief.
The Perforce package goes a long way toward meeting those goals. In the sales material, Perforce is said to be, “Easier to use than Kleenex, runs faster than a red Porsche ...” Let's check if this is a valid claim.
The Perforce system is a client/server system with just two binaries. The p4 binary is the client program. On Linux/Intel the p4 binary is just 55KB. The server program, p4d, is just 388KB. These files are the only ones you need. However, it is also a good idea to get the man pages p4.1 and p4d.1, as well as the manual (a PostScript file). You can find all of these files at http://www.perforce.com/.
The server program, p4d, is started like a daemon and does not need to be run as root. Personally, I have found it to be a good idea to create a special user, called Perforce, that runs the server program in its home directory. This user is not necessary, but it certainly helps to keep the system organized.
Installing Perforce is easy. First, the client program needs to be copied to a location that is in the default path (for example, /usr/local/bin). Then, the server program p4d needs to be started by the rc files at system startup and stopped at system shutdown. The programs do not require anything special in their environment.
Perforce is based on a true networked client/server approach. To do their work, the client programs connect to a TCP port on the server. Thus, you only need a TCP route from the client to the server. There is no need for an NFS-mounted file system.
The user does all the work (such as editing and compiling) on local files. These files are kept in syncronization with the server by a few simple p4 commands.
Each user of Perforce is a client and has a client view that is stored in the server. The client view is used by the server to determine which files in the server database the client wants and what local names the client wants for those files. The client view can be changed using the p4 client command. The server's database of files is called the “depot” in Perforce.
An interesting idea in Perforce is the notation of a change. A new numbered change is created each time you submit one or several files. For example, a bug-fix might require you to edit several files. By submitting these files together as a single change, you record the fact that the editing made in these files corresponds to a single change to the system. The changes have descriptions, and you can enter a text description of what you have changed and why. Changes are numbered so that a newer change always has a higher number.
You can identify a version of a file in 3 ways with Perforce:
You can say foo.c#version, where version is a file-specific version number.
You can also say foo.c@change, where change is a depot-wide change number. foo.c@115 is a valid identifier even if foo.c was only changed at change 110 and 120. In this case, foo.c@115 refers to the version of foo.c that was changed in change 110, i.e., the version of foo.c that was valid the moment change 115 was submitted.
As with many other systems Perforce has labels. Thus, the third way of identifying a version is foo.c@label.
The normal work with Perforce is done by the following commands:
p4 add informs Perforce that a local file in your work area is to be added to the files in the depot. p4 add only registers your intention to add the file, the actual adding is done by the command p4 submit.
p4 edit is used to open an existing file for editing—the p4d server is informed that you are going to edit the file. On many other systems this process is called checking-out. Changes are actually made by the p4 submit command.
p4 submit does the actual work for the previous two commands.
p4 get is used to get a file from the depot to the local workspace.
In addition to the normal commands for editing, there is a fair number of reporting commands such as p4 describe to learn more about a change, and p4 filelog to list the history of a file. All of these commands are easy and intuitive to use. There is also a p4 help command, as well as the man page.
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
- A Project to Guarantee Better Security for Open-Source Projects
- Concerning Containers' Connections: on Docker Networking
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- My Network Go-Bag
- Firefox Security Exploit Targets Linux Users and Web Developers
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- diff -u: What's New in Kernel Development
- Three More Lessons
- Calling All Linux Nerds!