Perforce 2007.3 Command Reference
<< Previous Chapter
Views
Table of Contents
Index
Perforce on the Web
Next Chapter >>
Index

File Types

Synopsis

Perforce supports six base file types:

File type modifiers are then applied to the base types allowing for support of RCS keyword expansion, file compression on the server, and more.

When a file is opened for add, Perforce attempts to determine the type of the file automatically. If the file is a regular file or a symbolic link, its type is set accordingly. Perforce then examines the first 8192 bytes of the file to determine whether it is text or binary. If any non-text characters are found, the file is assumed to be binary; otherwise, the file is assumed to be text. (Files in unicode environments are detected differently; for details, see the Internationalization Notes.)

Perforce administrators can use the type mapping feature (p4 typemap) to override Perforce's default file type detection mechanism. This feature is useful for binary file formats (such as Adobe PDF, or Rich Text Format) where files can start with 8192 or more characters of ASCII text, and might otherwise be mistaken for text files.

Base filetypes

The base Perforce file types are:

Keyword
Description
Comments
Server Storage

text

Text file

Treated as text on the client. Line-ending translations are performed automatically on Windows and Macintosh clients.

deltas in RCS format

binary

Non-text file

Accessed as binary files on the client. Stored compressed within the depot.

full file,
compressed

symlink

Symbolic link

UNIX clients (and the BeOS client) access these as symbolic links. Non-UNIX clients treat them as (small) text files.

deltas in RCS format

apple

Multi-forked Macintosh file

AppleSingle storage of Mac data fork, resource fork, file type and file creator.

For full details, please see the Mac client release notes.

full file,
compressed, AppleSingle format.

resource

Macintosh resource fork

The only file type for Mac resource forks in Perforce 99.1 and before. Still supported, but the apple file type is preferred.

For full details, please see the Mac client release notes.

full file,
compressed

unicode

Unicode file

Perforce servers operating in unicode mode support the unicode file type. These files are translated into the local character set specified by P4CHARSET.

Perforce servers not in unicode mode do not support the unicode file type.

For details, see the Internationalization Notes.

UTF-8

utf16

Unicode file

If the Perforce server is operating in unicode mode, files are translated into the local character set as specified by P4CHARSET.

If the Perforce server is operating in non-unicode mode, files are transferred as UTF-8, and translated to UTF-16 (with byte order mark, in the byte order appropriate for the client machine) in the client workspace.

For details, see the Internationalization Notes.

UTF-8

File type modifiers

The file type modifiers are:

Modifier
Description
Comments

+w

File is always writable on client

+x

Execute bit set on client

Used for executable files.

+ko

Old-style keyword expansion

Expands only the $Id$ and $Header$ keywords:

This pair of modifiers exists primarily for backwards compatibility with versions of Perforce prior to 2000.1, and corresponds to the +k (ktext) modifier in earlier versions of Perforce.

+k

RCS keyword expansion

Expands RCS (Revision Control System) keywords.

RCS keywords are case-sensitive.

When using keywords in files, a colon after the keyword (for instance, $Id:$) is optional.

Supported keywords are:

  • $Id$
  • $Header$
  • $Date$
  • $DateTime$
  • $Change$
  • $File$
  • $Revision$
  • $Author$

+l

Exclusive open (locking)

If set, only one user at a time will be able to open a file for editing.

Useful for binary file types (such as graphics) where merging of changes from multiple authors is meaningless.

+C

Server stores the full compressed version of each file revision

Default server storage mechanism for binary files.

+D

Server stores deltas in RCS format

Default server storage mechanism for text files.

+F

Server stores full file per revision, uncompressed

Useful for large binaries, or for long ASCII files that aren't read by users as text, such as PostScript files.

+S

Only the head revision is stored on the server

Older revisions are purged from the depot upon submission of new revisions. Useful for executable or .obj files.

+Sn

Only the most recent n revisions are stored on the server, where n is a number from 1 to 10, or 16, 32, 64, 128, 256, or 512.

Older revisions are purged from the depot upon submission of more than n new revisions, or if you change an existing +Sn file's n to a number less than its current value.

+m

Preserve original modtime

The file's timestamp on the local filesystem is preserved upon submission and restored upon sync. Useful for third-party DLLs in Windows environments.

A file's type is normally preserved between revisions, but can be overridden or changed with the -t flag during add, edit, or reopen operations:

The filetype argument is specified as [basetype]+modifiers. For example, to change script.sh's type to executable text with RCS keyword expansion, use p4 edit -t text+kx script.sh.

Partial filetypes are also acceptable. For example, to change an existing text file to text+x, use p4 reopen -t +x script.sh. Most partial filetype modifiers are added to the filetype, but the storage modifiers (+C, +D, and +F) replace the file's storage method. To remove a modifier, you must specify the full filetype.

Perforce file types for common file extensions

The following table lists recommended Perforce file types and modifiers for common file extensions.

File Type
Perforce file type
Description

.asp

text

Active server page file

.avi

binary+F

Video for Windows file

.bmp

binary

Windows bitmap file

.btr

binary

Btrieve database file

.cnf

text

Conference link file

.css

text

Cascading style sheet file

.doc

binary

Microsoft Word document

.dot

binary

Microsoft Word template

.exp

binary+w

Export file (Microsoft Visual C++)

.gif

binary+F

GIF graphic file

.htm

text

HTML file

.html

text

HTML file

.ico

binary

Icon file

.inc

text

Active Server include file

.ini

text+w

Initial application settings file

.jpg

binary

JPEG graphic file

.js

text

JavaScript language source code file

.lib

binary+w

Library file (several programming languages)

.log

text+w

Log file

.mpg

binary+F

MPEG video file

.pdf

binary

Adobe PDF file

.pdm

text+w

Sybase Power Designer file

.ppt

binary

Microsoft Powerpoint file

.xls

binary

Microsoft Excel file

.zip

binary+F

ZIP compressed archive file

For more about mapping file names to Perforce filetypes, see the p4 typemap command.

Keyword Expansion

RCS keywords are expanded as follows:

Keyword
Expands To
Example

$Id$

File name and revision number in depot syntax

$Id: //depot/path/file.txt#3 $

$Header$

Synonymous with $Id$

$Header: //depot/path/file.txt#3 $

$Date$

Date of last submission in format YYYY/MM/DD

$Date: 2000/08/18 $

$DateTime$

Date and time of last submission in format YYYY/MM/DD hh:mm:ss

Date and time are as of the local time on the Perforce server at time of submission.

$DateTime: 2000/08/18 23:17:02 $

$Change$

Perforce changelist number under which file was submitted

$Change: 439 $

$File$

File name only, in depot syntax (without revision number)

$File: //depot/path/file.txt $

$Revision$

Perforce revision number

$Revision: #3 $

$Author$

Perforce user submitting the file

$Author: edk $

Usage Notes

For instance, changing a file's type by adding the +Sn (temporary object) modifier tells Perforce to store only the most recent n revisions of the file in the depot. If you change an existing file into a temporary object, subsequent revisions (after the nth) will purge the revisions stored after the old head revision, but revisions to the file stored in the depot before the +Sn modifier was used will remain unaffected. (Syncing to a non-head revision submitted after the +Sn modifier was used will delete the file from your workspace. Such revisions are displayed as purge operations in the output of p4 filelog.)

The most common case where this is useful is development involving the third-party DLLs often encountered in Windows environments. Because the timestamps on such files are often used as proxies for versioning information (both within the development environment and also by the operating system), it is sometimes necessary to preserve the files' original timestamps regardless of a Perforce user's client settings.

The +m modifier on a file allows this to happen; if set, Perforce will ignore the modtime ("file's timestamp at time of submission") or nomodtime ("date and time on the client at time of sync") option setting of the client workspace when syncing the file, and always restore the file's original timestamp at the time of submit.


Perforce 2007.3 Command Reference
<< Previous Chapter
Views
Table of Contents
Index
Perforce on the Web
Next Chapter >>
Index
Please send comments and questions about this manual to [email protected].
Copyright 1999-2007 Perforce Software. All rights reserved.
Last updated: 11/29/07