|
Synopsis
Perforce supports five base file types:
- text files,
- compressed binary files,
- native apple files on the Macintosh,
- Mac resource forks, and
- symbolic links.
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 1024 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.
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 1024 or more characters of ASCII text, and might otherwise be mistaken for text files.
The base Perforce file types are:
Keyword
|
Description
|
Comments
|
Server Storage Type
|
|---|
|
text
|
Text file
|
Treated as text on the client. Line-ending translations are performed automatically on Windows and Macintosh clients.
|
delta
|
|
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.
|
delta
|
|
apple
|
Multi-forked Macintosh file
|
AppleSingle storage of Mac data fork, resource fork, file type and file creator. New to Perforce 99.2.
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 we recommend using the new apple file type instead.
For full details, please see the Mac client release notes.
|
full file,
compressed
|
|
unicode
|
Unicode file
|
Perforce servers operating in internationalized mode support a Unicode file type. These files are translated into the local character set.
For details, see the System Administrator's Guide.
|
Stored as UTF-8
|
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
|
Useful 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 overwritten within the depot. Useful for executable or .obj files.
|
|
+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:
- p4 add -t filetype filespec adds the files as the specified type.
- p4 edit -t filetype filespec opens the file for edit as the specified type. The file's type is changed to the specified filetype only after it is submitted to the depot.
- p4 reopen -t filetype filespec changes the type of a file already open for add or edit.
The filetype argument is specified as basetype+modifiers. For example, to change file foo's type to executable text with RCS keyword expansion, use p4 edit -t text+kx foo.
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
- The type of an existing file can be determined with p4 opened or p4 files.
- Delta storage (the default mode with text files) is a method whereby only the differences (or deltas) between revisions of files are stored. Full file storage (the default mode with binary files) involves the storage of the entire file. The file's type determines whether full file or delta storage is used. Perforce uses RCS format for delta storage.
- Some of the file types are compressed to gzip format for storage in the depot. The compression occurs during the submission process, and decompression happens while syncing. The process is transparent to the user; the client workspace always contains the file as it was submitted.
- Symbolic links on non-UNIX clients appear as small text files containing a relative path to the linked file. Editing these files on a non-UNIX client should be done with caution, as submitting them to the depot may result in a symbolic link pointing to a nonexistent file on the UNIX client.
- Some file type changes do not affect earlier revisions stored in the depot. For instance, changing a file's type by adding the +S (temporary object) modifier tells Perforce to store only the head revision of the file in the depot. If you do this to a previously-existing file, any subsequent changes to the file will overwrite the one stored at the head revision, but revisions to the file stored in the depot before the +S modifier was used will remain unaffected.
- The modtime (+m) modifier is a special case: It is intended for use by developers who need to preserve a file's original timestamp. (Normally, Perforce updates the timestamp when a file is synced.) It allows a user to ensure that the timestamp of a file in a client workspace after a p4 sync will be the original timestamp existing on the file at the time of submission (that is, not the time at the Perforce server at time of submission, and not the time on the client at the time of sync).
- 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.
- Versions of Perforce prior to 99.1 used a set of keywords to specify file types. These keywords are still supported, but have been made redundant. The following table lists the old keywords alongside their current base file types and modifiers:
Old Keyword
|
Description
|
Base Filetype
|
Modifiers
|
|---|
|
text
|
Text file
|
text
|
none
|
|
xtext
|
Executable text file
|
text
|
+x
|
|
ktext
|
Text file with RCS keyword expansion
|
text
|
+k
|
|
kxtext
|
Executable text file with RCS keyword expansion
|
text
|
+kx
|
|
binary
|
Non-text file
|
binary
|
none
|
|
xbinary
|
Executable binary file
|
binary
|
+x
|
|
ctext
|
Compressed text file
|
text
|
+C
|
|
cxtext
|
Compressed executable text file
|
text
|
+Cx
|
|
symlink
|
Symbolic link
|
symlink
|
none
|
|
resource
|
Macintosh resource fork
|
resource
|
none
|
|
ltext
|
Long text file
|
text
|
+F
|
|
xltext
|
Executable long text file
|
text
|
+Fx
|
|
ubinary
|
Uncompressed binary file
|
binary
|
+F
|
|
tempobj
|
Temporary object
|
binary
|
+S
|
|
xtempobj
|
Temporary executable object
|
binary
|
+Sx
|
|