Less common tasks

This chapter discusses less common tasks.

Work offline

The preferred method of working offline (without access to the Helix server) is to use DVCS (distributed versioning) features. For details, refer to Using Helix for Distributed Versioning.

If you work offline, you must manually reconcile your work with the Helix service when you regain access to it. The following method for working detached assumes that you work on files in your workspace or update the workspace with your additions, changes, and deletions before you update the depot:

To work offline:

  1. Work on files without issuing p4 commands. Instead, use operating system commands to change the permissions on files.
  2. After the network connection is re-established, use p4 status or p4 reconcile to find all files in your workspace that have changed.
  3. Submit the resulting changelist(s).

To detect changed files, issue the p4 status or p4 reconcile commands. The commands perform essentially the same function, but differ in their default behavior and output format.

Command Description

p4 reconcile

When called without arguments, p4 reconcile opens the files in a changelist. To preview an operation, you must either use the -n option with p4 reconcile, or use the p4 status command.

p4 status

When called without arguments, p4 status only previews the results of the workspace reconciliation. You must use either p4 status -A (or some combination of the -e, -a, or -d options) to actually open the files in a changelist.

Ignoring groups of files when adding

Sometimes development processes result in the creation of extraneous content that should not be submitted to the depot. Compilers produce object files and executables during development, text editors and word processors produce backup files, and you may have your own personal conventions for notes on work in progress.

To ignore files (or groups of files) when adding, create a file with a list of file specifications you wish to ignore, and set the P4IGNORE environment variable to point to this file.

When you add files, the full local path and parent directories of any file to be added are searched for P4IGNORE files. If any P4IGNORE files exist, their rules are added to a list, with greater precedence given to P4IGNORE rules closest to the file being added.

The syntax for P4IGNORE files is not the same as Helix syntax. Instead, it is similar to that used by other versioning systems: files are specified in local syntax, a # character at the beginning of a line denotes a comment, a ! character at the beginning of a line excludes the file specification, and the * wildcard matches substrings. The Helix wildcard of ... is not permitted.

Character Meaning in P4IGNORE files

*

Matches anything except slashes. Matches only within a single directory. Case sensitivity depends on your client platform.

!

Exclude the file specification from consideration.

#

Comment character; this line is ignored.

Example 30. Ignoring groups of files when adding.

Bruno unit tests his code before submitting it to the depot and does not want to accidentally add any object files or generated executables when reconciling his workspace.

Bruno first sets P4IGNORE to point to the correct file: 

$ export P4IGNORE=.p4ignore

He then creates the following file and stores it as .p4ignore in the root of his workspace: 

# Ignore .p4ignore files
.p4ignore
# Ignore object files, shared libraries, executables
*.dll
*.so
*.exe
*.o
# Ignore all text files except readme file
*.txt
!readme.txt

The next time he runs a command (such as p4 add *.*), the rules are applied across the entire workspace.

To override (or ignore) the P4IGNORE file, use the -I option with the p4 add, p4 reconcile, or p4 status commands.

Reporting ignored files

The p4 ignores command reports the ignore mappings in effect. Specifically, it displays the ignore mappings computed from the rules in the P4IGNORE file.

If you add the -i option, it reports whether a particular file or set of files will be ignored.

For more information on p4 ignores, see the p4 ignores page in the P4 Command Reference.

Locking files

After you open a file, you can lock it to prevent other users from submitting it before you do. The benefit of locking a file is that conflicts are prevented, but when you lock a file, you might prevent other team members from proceeding with their work on that file.

Preventing multiple resolves by locking files

Without file locking, there is no guarantee that the resolve process ever ends. The following scenario demonstrates the problem:

  1. Bruno opens file for edit.
  2. Gale opens the same file in her client for edit.
  3. Bruno and Gale both edit their client workspace versions of the file.
  4. Bruno submits a changelist containing that file, and his submit succeeds.
  5. Gale submits a changelist with her version of the file; her submit fails because of file conflicts with the new depot’s file.
  6. Gale starts a resolve.
  7. Bruno edits and submits a new version of the same file.

  8. Gale finishes the resolve and attempts to submit; the submit fails and must now be merged with Bruno’s latest file.

    …​and so on.

To prevent such problems, you can lock files, as follows.

  1. Before scheduling a resolve, lock the file.
  2. Sync the file (to schedule a resolve).
  3. Resolve the file.
  4. Submit the file.
  5. Helix automatically unlocks the file after successful changelist submission.

To list open locked files on UNIX, issue the following command:

$ p4 opened | grep "*locked*"

Preventing multiple checkouts

To ensure that only one user at a time can work on the file, use the +l (exclusive-open) file type modifier. For example: 

$ p4 reopen -t binary+l file

Although exclusive locking prevents concurrent development, for some file types (binary files), merging and resolving are not meaningful, so you can prevent conflicts by preventing multiple users from working on the file simultaneously.

Your Helix administrator can use the p4 typemap command to ensure that all files of a specified type (for instance, //depot/.../*.gif for all .gif files) can only be opened by one user at a time. See the P4 Command Reference.

The difference between p4 lock and +l is that p4 lock allows anyone to open a file for edit, but only the person who locked the file can submit it. By contrast, a file of type +l prevents more than one user from opening the file.