|Last modified: 14-11-2012|
Perforce can be used for free if you only need two users (login) and two client workspaces (computer). You can switch users through the Win4 client (User | View Users, select a user, and select User | Switch to...), and clients (ClientSpec | View Client Specs,
In Perforce jargon, a "client" is a user profile, which includes an "owner" (user), a "host" (computer from which the user will connect to the p4d server), and a "workspace" (a directory on his computer where files will be checked out from the depot). When used in evaluation mode, a Perforce server only allows up to two clients.
P4d is the server daemon. It creates a bunch of db.* files when started. The client application is either p4 (command line-based), or p4win (GUI-based; No graphical client is available for Linux.) Files are kept in a depot on the server where Perforce is running. A server can handle more than one depot, and client workspaces can be located in remote networks. Perforce recommends against replicating a depot on another, remote Perforce server, because it increases the risk of merging conflicts. (From online documentation) Performance can be increased for remote users by using restrictive client views and access permissions so that each user is accessing only the depots and subdirectories s/he is working on.
Windows users at network-bound sites will be more efficient using the Perforce p4 command line interface rather than the P4win GUI, because the current release of P4win makes frequent behind-the-scenes data update requests from the server.
Support for accesing remote depots
The Perforce remote depot support allows you to access files from a venus:1666 depot while you are connected to mars:1666 as your local server. For instance, you could define a remote depot called "//venus" with a mapping to the venus:1666 "//depot2" path. Once you've done this, you can use p4 commands to refer to files in the //venus path. E.g., p4 diff2 //venus/elm2.1/... //depot/elm2.1/... diffs all the files in the venus:1666 //depot2/elm2.1 path with their counterparts in the mars:1666 //depot/elm2.1 path.
When you access files in the //venus path, p4 is not communicating directly with the venus:1666 server. Instead, your p4 (or P4win) program communicates with the mars:1666 server, which in turn communicates with the venus:1666 server.
Limitation: Access is read only, Servers must be running the same 'p4d' versions, NT servers and Unix servers are incompatible, No metadata access, label and client names are those on the local server (Files in a remote depot may be accessed by label name or client name, but the local server's label and client specifications will be used in these cases), One-sided integration records, Remote access can seriously degrade local performance
Conclusion: Use remote depots to share code, read-only, with remote sites that do not need to make any change to the code. If they do, they'll have to connect to the original server where live data live.
As a first test, we'll install both the server and the client on the same NT host:
While the Client workspace (eg. C:\P4CLIENT in the example above) holds files while they're checked out, Perforce keeps the File Depot in its depot\ sub-directory (eg. d:\Program Files\Perforce\depot\). Perforce seems to use RCS as its file format, and files are kept in the depot even after having been marked as deleted through the Perforce client, probably to protect the innocents.
When checking a file out, it is not automatically extracted from the depot into the client workspace, so if you removed files from the client workspace...
Typically each engineer user has his or her own dedicated client workspace, and may also use other special-purpose or project workspaces. The client workspace specification defines a view, or subset, of files from the repository that are of interest to the user. The workspace itself contains physical copies of the files in its view.
The Perforce Server comprises three main sub-components: a request handler, a data manager and a file librarian. The request handler acts as an executive, sequencing actions to carry out client requests and managing communication with the client. The data manager implements optimized database services based on the Berkeley DB database package, customized for multi-user support. It maintains a meta-database describing the status and history of versioned files in the depot and transactions against the depot. The librarian is a highly efficient file archiver that stores repository files on disk local to the server. It writes text file versions in an RCS-compatible, reverse-delta format; binary file versions are stored in a standard compressed format.
WebKeeper module, which uses the Perforce API to enable an Apache HTTP web server to act as a Perforce client and request versioned files directly from a Perforce server.
P4FTP allows FTP clients, including Dreamweaver, Netscape, and Internet Explorer, to access Perforce depot files via FTP. It can be installed in addition to or instead of an FTP server on Unix or Windows NT/2000.
Perfbrowse - Web/Perforce Browser: This simple depot browser is implemented in Perl 4 and runs as a CGI script on your web server. It allows you to browse your Perforce depot using a normal web browser.
P4DB - Web/Perforce Browser: Another way to browse your Perforce depot via the Web is withP4DB. Lots of features; provides some nice reporting and cross-referencing. Contributed by Fredric Fredriksson of MYDATA Automation.
Perforce provides a primitive change tracking system. Change requests are "jobs," and the developer can link many changelists to one job or one changelist to many jobs.
However, Perforce needs a much better change tracking tool before it can be considered a change management system. Fortunately, a "Defect Tracking Integration" is due for release in March 2001, and by the time you read this, the integrations to TeamShare's TeamTrack (see Dana Cline's "Tracking Bugs on the Web," Nov. 1999) and Mozilla's (www.mozilla.org) Bugzilla should be available. (The beta copies of these integrations are available at www.ravenbrook.com.) During integration, the change information is copied from the Perforce job record to the change tracking tool record, and vice versa. It purportedly integrates the benefits of Perforce's configuration management, especially changelists, with the benefits of a change tracking tool. P4DTI.
Username = NT User
When booting, client = "<NT hostname> has not been defined"
When creating first client, owner = Fred is defined when installing the application?
To edit a user, switch to it first
To add files to depot, must be located in workspace, then click on Submit
Why no edit from remote host?
To uninstall Perforce, run install EXE
Guess a client is an instance of Perforce that is installed on a given computer, while a user is an account defined in the Perforce server