|
|
|
|
|
|
|
|
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:
The normal work with Perforce is done by the following commands:
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.
One of the particularly strong points of Perforce is the way it handles branches, called ``inter-file branching''.
On many other systems the branch specification is in some way part of the version numbering or version selection mechanism. This is counter intuitive and is often a cause of confusion. Other systems also make branches of individual files.
Perforce handles branch naming in the same way that you would without a code-management system. In Perforce, the directory my_project/new_branch/ contains the new branch of my_project/old_branch. By making the branch naming a part of the directory tree structure, Perforce has created a very natural way to interact with and think about branches.
In this way a branch is simultaneously created for the complete project, not just for an individual file. This method also helps to keep the branches consistent. A copying algorithm in the server prevents this approach from using more disk space than other approaches.
Above, I have described the normal use of the Perforce branching mechanism. However, the Perforce branching mechanism is even more powerful. It is possible to specify that file trees or individual files are branches of each other. It is even possible to designate two totally unrelated files or directory trees as branches and migrate changes between them.
The specification of branches is done by a branch view. The branch view can contain a simple or arbitrarily complex mapping between file names in the two branches.
Perforce uses the powerful command p4 integ and p4 resolve to integrate changes between the branches and to resolve conflicts.
Perforce is a very fast, code-management system. Code-management actions, such as labelling, checking in (P4 submit) and checking out (p4 edit) are several magnitudes faster than ClearCase, another code-management system.
With Perforce, all normal work such as editing and compiling is done on local files in your work area, making Perforce much faster than most other systems.
Perforce has a number of advanced features. I cannot list all of them (much less describe them all) in this space, but I will mention a few.
Perforce can have distributed depots. You can run Perforce over WANs, and you can even run it encrypted over the Internet. You can use Perforce with IP-tunneling and firewalls. Perforce can have change submission triggers for external processes.
Perforce has support for off-line clients. That is, it is possible to disconnect a client computer and make changes to the local files in the workspace, and afterwards let Perforce detect the changes and bring them into the depot.
You can download all of Perforce, except the license file, from ftp://ftp.perforce.com/. The license file determines how many users the server accepts. Without a license file, there can be only 2 users. The cost of purchasing Perforce (i.e., the license file) is $500US/user. If you purchase Perforce, they e-mail the license file to you. Perforce has announced:
Non-commercial users of Free-BSD and LINUX may obtain Perforce servers supporting an unlimited number of end users gratis. This includes upgrades, but not support. Execution of a Perforce non-commercial license agreement is required.Answering a direct question, Christopher Seiwald of Perforce, said:
We cannot guarantee non-commercial users support, but we try not to discriminate between commercial users, evaluation users and non-commercial users.Perforce is available for Linux x86 and Linux Alpha, as well as for Free-BSD and many commercial systems.
Perforce has provided excellent support to me. No matter how absurd the question or how absurd the task I am attempting, I have always received a good answer by e-mail within 18 hours. Perforce has remarkably good e-mail support. I have asked other customers of Perforce on the Net, and they have all been pleased.
I have used Perforce both professionally (see ``MYDATA's Industrial Robots'', LJ Issue 39, July 1997) and as a home-hobby programmer. I find Perforce to be a good product with good support. I find other CM products that I have used professionally to be remarkably poor by comparison.
Perforce is not just a technically good product--it is also easy and intuitive to use. Considering the favorable licensing policy of Perforce, I recommend you download Perforce and test it for yourself.
Tom Björkholm is a software engineer at Ericsson Business Networks. He has no connection with Perforce, except as a user. He has used Linux since version 0.95. When not programming, he enjoys sailing. He welcomes comments sent to tom.bjorkholm@swipnet.se.