Perforce supports a set of file types that enable it to determine how files are stored by the Perforce server and whether the file can be diffed. When you add a file, Perforce attempts to determine the type of the file automatically: Perforce first determines whether the file is a regular file or a symbolic link, and then examines the first part of the file to determine whether it's
text or
binary. If any nontext 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; see
Perforce file type detection and Unicode.)
To determine the type of a file under Perforce control, issue the p4 opened or
p4 files command. To change the Perforce file type, specify the
-t filetype flag. For details about changing file type, refer to the descriptions of
p4 add,
p4 edit, and
p4 reopen in the
Perforce Command Reference.
|
|
|
|
|
|
|
|
AppleSingle storage of Macintosh data fork, resource fork, file type and file creator.
|
full file, compressed, AppleSingle format
|
|
|
|
|
|
|
|
|
(Obsolete) This type is supported for backward compatibility, but the apple file type is recommended.
|
|
|
|
|
UNIX and BeOS client machines treat these files as symbolic links. Non-UNIX client machines treat them as text files.
|
|
|
|
|
Synced as text in the workspace. Line-ending translations are performed automatically.
|
|
|
|
|
Perforce servers operating in unicode mode support the unicode file type. These files are translated into the local character set specified by P4CHARSET.
For details, see the Internationalization Notes.
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
Server stores the full compressed version of each file revision
|
Default server storage mechanism for binary files and newly-added text files larger than 10MB.
|
|
|
|
|
|
|
|
For large ASCII files that aren't treated as text, such as PostScript files, where storing the deltas is not useful or efficient.
|
|
|
RCS (Revision Control System) keyword expansion
|
RCS keywords are case-sensitive. A colon after the keyword (for example, $Id:$) is optional.
|
|
|
|
Expands only the $Id$ and $Header$ keywords. Primarily for backwards compatibility with versions of Perforce prior to 2000.1, and corresponds to the +k ( ktext) modifier in earlier versions of Perforce.
|
|
|
|
Useful for binary file types (such as graphics) where merging of changes from multiple authors is not possible.
|
|
|
|
The file's timestamp on the local file system is preserved upon submission and restored upon sync. Useful for third-party DLLs in Windows environments, because the operating system relies on the file's timestamp. By default, the modification time is set to the time you synced the file.
|
|
|
|
Older revisions are purged from the depot upon submission of new revisions. Useful for executable or .obj files.
|
|
|
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. For details, see the Command Reference.
|
|
|
|
Not recommended, because Perforce manages the read-write settings on files under its control.
|
|
|
|
|
|
|
|
The server runs an archive trigger to access the file. See the System Administrator's Guide for details.
|
File revisions of binary files are normally stored in full within the depot, but only changes made to text files since the previous revision are normally stored. This approach is called
delta storage, and Perforce uses RCS format to store its deltas. The file's type determines whether
full file or
delta storage is used.
Some file types are compressed to gzip format when stored in the depot. The compression occurs when you submit the file, and decompression happens when you sync (copy the file from the server to the workspace). The client workspace always contains the file as it was submitted.
The Perforce server can be run in Unicode mode to activate support for filenames and Perforce metadata that contain Unicode characters, or in non-Unicode mode, where filenames and metadata must be ASCII, but textual files containing unicode content are still supported.
If you need to manage textual files that contain Unicode characters, but do not need Unicode characters in Perforce metadata, you do not need to run your server in Unicode mode. Assign the Perforce
utf16 file type to textual files that contain Unicode characters.
In either mode, Perforce supports a set of file types that enable it to determine how a file is stored by the Perforce server and whether the file can be diffed. The following sections describe the considerations for managing textual files in Unicode environments.
Unicode mode servers translate the contents of unicode files into the character set specified by
P4CHARSET. The following table provides more details about how Unicode-mode servers manage the various types of text files.
Non-unicode-mode servers do not translate or verify the contents of unicode files. Instead, the UTF-8 data is converted to UTF-16 using the byte order appropriate to the client platform. To ensure that such files are not corrupted when you edit them, save them as UTF-8 or UTF-16 from within your editing software.
In both Unicode mode and non-Unicode mode, if you do not assign a file type when you add a file to the depot, Perforce attempts to detect file type by scanning the first 8192 characters of the file. If nonprintable characters are detected, the file is assigned the
binary file type. (In Unicode mode, a further check is performed: if there are no nonprintable characters, and there are high-ASCII characters that are translatable using the character set specified by
P4CHARSET, the file is assigned the
unicode file type.)
Finally (for servers running in Unicode mode or non-Unicode mode), if a UTF-16 BOM is present, the file is assigned the
utf16 file type. Otherwise, the file is assigned the
text file type. (In Unicode mode, a further check is performed: files with high-ASCII characters that are undefined in the character set specified by
P4CHARSET are assigned the
binary file type.)
In most cases, there is no need to override Perforce's default file type detection. If you must override Perforce's default file type detection, you can assign Perforce file types according to a file's extension, by issuing the
p4 typemap command. For more about using the typemap feature, refer to the
Perforce System Administrator's Guide, and the
Perforce Command Reference.
Some file formats (for example, Adobe PDF files, and Rich Text Format files) are actually
binary files, but they can be mistakenly detected by Perforce as being
text. To prevent this problem, your system administrator can use the
p4 typemap command to specify how such file types are stored. You can always override the file type specified in the typemap table by specifying the
-t filetype flag.
Normally, Perforce updates the timestamp when a file is synced. The modification time (
+m) modifier is intended for developers who need to preserve a file's original timestamp. This modifier enables you to ensure that the timestamp of a file synced to your client workspace is the time on the client machine when the file was submitted.
Windows uses timestamps on third-party DLLs for versioning information (both within the development environment and also by the operating system), and the
+m modifier enables you to preserve the original timestamps to prevent spurious version mismatches. The
+m modifier overrides the client workspace
[no]modtime setting (for the files to which it is applied). For details about this setting, refer to
File type modifiers.
RCS (Revision Control System), an early version control system, defined keywords that you can embed in your source files. These keywords are updated whenever a file is committed to the repository. Perforce supports some RCS keywords. To activate RCS keyword expansion for a file, use the
+k modifier. RCS keywords are expanded as follows.
Copyright 2005-2009 Perforce Software.
