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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide