[Top] [Prev] [Next]

Perforce Basics:
Miscellaneous Topics

The manual thus far has provided an introduction to the basic functionality provided by Perforce; the next chapters covers the more advanced features. In between are a host of other, smaller facilities; this chapter covers these topics. Included here is information on the following:

Command Line Flags
Common to All Perforce Commands

 Five flags are available for use with all Perforce commands. These flags are given between the system command p4 and the command argument taken by p4. These flags are:

Flag

Meaning

Example

-c clientname Runs the command on the specified client. Overrides the P4CLIENT environment variable. p4 -c joe edit //depot/foo Opens file foo for editing under client workspace joe.
-d directory Specifies the current directory, overriding the environment variable PWD. p4 -d ~elm/src edit help Opens file help for edit; the help file is found relative to
~elm/src.
-p server_addr Gives the p4d server's listening address, overriding P4PORT. p4 -p mama:1818 clients Reports a list of clients on the server on host mama, port 1818.
-u username Specifies a Perforce user, overriding the P4USER, USER, and USERNAME environment variables. p4 -u bill user Presents the p4 user form to edit specification for user bill. Only commands that the specified user has permissions on may be run.
-x filename Instructs p4 to read arguments, one per line, from the named file. <see Working Detached section, below>

All Perforce commands can take these flags, even commands for which this flag usage is clearly useless (for example, p4 -u bill -d /usr/joe help).

Working Detached

Under normal circumstances, users work in their client workspace with a functioning network connection to a Perforce server. As they edit files, they are supposed to announce their intentions to the server with p4 edit, and the server responds by noting the edit in the depot's metadata, and by unlocking the file in the client workspace. However, it is not always possible for a network connection to be present; a method is needed for users to work entirely detached from the server

The scheme is as follows:

Finding Changed Files
with `p4 diff'

 The p4 diff reporting command is used to compare a file in the client workspace with the corresponding file in the depot. Its behavior can be modified with two flags:

p4 diff Variation

Meaning

p4 diff -se Tells the names of unopened files that are present on the client, but whose contents are different than the files last taken by the client with p4 get. These files are candidates for p4 edit.
p4 diff -sd Reports the names of unopened files missing from the client. These files are candidates for p4 delete.

Using `p4 diff' to
Update the Depot

The p4 diff variations described above can be used in combination with the -x flag to bring the state of the depot in sync with the changes made to the client workspace.

To open changed files for edit after working detached, use

p4 diff -se > CHANGED_FILES
followed by

p4 -x CHANGED_FILES edit
To delete files from the depot that were removed from the client workspace, use
p4 diff -sd > DEL_FILES
p4 -x DEL_FILES delete

As always, these edit and delete requests are stored in a changelist, which is not processed until the p4 submit command is given.

Like all other perforce commands, p4 diff can limit its operations to files matching patterns given on the command line.

Refreshing files

The process of syncing a depot with a formerly-detached client workspace has a converse: it is possible for Perforce to become confused about the contents of a client workspace through the accidental use of UNIX commands. For example, suppose that you accidently delete a client workspace file via the UNIX rm command, and that the file is one that you wanted to keep. Even after a submit, p4 have will still list the file as being present in the workspace.

Just as the process described above will bring the depot in sync with the client workspace, p4 refresh can be used to bring the client workspace in sync with the files the depot thinks you have. This command is mostly a recovery tool for bringing the client workspace back into sync with the depot after accidentally removing or damaging files managed by Perforce.

p4 refresh affects only unopened files. The commands p4 refresh and p4 revert perform complementary functions. p4 refresh brings unopened files into the client workspace; p4 revert brings the contents of opened files into the workspace. When both commands are run with no file arguments, all the files in the depot are brought into the workspace.

`p4 client' Options

The form brought up by p4 client has an option field, which takes two values: 
Client: eds_elm
Owner: ed
Description:
    Created by ed.
Root:  /usr/edk/elm
Options:        nomodtime noclobber

View:
    //depot/elm_proj/...         //eds_elm/...

The `modtime' option controls the modification times of client files when gotten from the depot with p4 get, p4 refresh, or p4 revert. The default, nomodtime, leaves the modification times of files in the client as the times these files were submitted to the depot. If this option is set to modtime, the modification date is set to the time the file was copied into the client.

The `clobber' option, which can be set to clobber or noclobber, controls how p4 get behaves while retrieving files from the depot that already exist in the client. noclobber, the default, tells p4 get to avoid clobbering client files that aren't open in Perforce but have otherwise been made writable by the user. clobber will overwrite these files.

Recommendations for
Organizing the Depot

The default view brought up by p4 client maps the entire depot to the entire client workspace. If the client workspace is named eds_elm, the default view would look like this:

//depot/... //eds_elm/...
This is the easiest mapping, and can be used for the most simple Perforce depots, but mapping the entire depot to the workspace can lead to problems later on. Suppose your server currently stores files for only one project, but later on another project is added. Everyone who has a client workspace mapped as above will wind up receiving all the files from both projects in their workspaces. Additionally, the default view does not facilitate branch creation.

The easiest and safest way to organize the depot, even from the start, is to create one subdirectory per project within the depot. For example, if your company is working on three projects, codenamed foo, bar, and zeus, three subtrees might be created within the depot: //depot/foo, //depot/bar, and //depot/zeus. If Joe is working on the foo project, his mapping might look like this:

//depot/foo/...       //joe/...
And Sarah, who's working on the bar and zeus projects, might set up her client workspace as:

//depot/bar/...      //sarah/bar/...

        //depot/zeus/...    //sarah/zeus/...
This sort of organization can be extended on the fly to as many projects and branches as are needed.

A second way of solving the same problem would be to ask your system administrator to create one depot for each project or branch.

Renaming Files

Although Perforce doesn't have a rename command, a file can be renamed by using
p4 integrate to copy the file from one location in the depot to another, deleting the file from the original location, and then submitting the changelist that includes the integrate and the delete. The process is as follows:
p4 integrate from_files to_files
p4 delete from_files
p4 submit

The from_file and to_file specifiers may include wildcards, as long as they are matched on both sides. Write access is needed on all files.

Reading Forms from Standard Input;
Writing Forms to Standard Output

Any commands that require the user to fill in a form, such as the p4 client and p4 submit commands, can read the form from standard input with the -i flag. An example is

p4 client -i < filename
where filename contains the field names and values expected by the form.

Similarly, the -o flag can be used to write a form specification to standard output.

The commands that display forms and can use these flags are
p4 branch p4 change
p4 client p4 job
p4 label p4 protect
p4 submit p4 user


[Top] [Prev] [Next]

[email protected]
Copyright © 1997, Perforce Software. All rights reserved.