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. If a
text file is 10MB or larger, it is assumed to be of type
ctext (
text+C), and the file is compressed and stored in full on the server, rather than as deltas.
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.
|
|
|
|
|
|
|
|
Treated as text on the client. Line-ending translations are performed automatically on Windows and Macintosh clients.
|
|
|
|
|
|
|
|
|
|
UNIX clients (and the BeOS client) access these as symbolic links. Non-UNIX clients treat them as (small) text files.
|
|
|
|
Multi-forked Macintosh file
|
AppleSingle storage of Mac data fork, resource fork, file type and file creator.
|
full file, compressed, AppleSingle format.
|
|
|
|
The only file type for Mac resource forks in Perforce 99.1 and before. Still supported, but the apple file type is preferred.
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
Useful for binary file types (such as graphics) where merging of changes from multiple authors is meaningless.
|
|
|
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.
|
|
|
|
|
|
|
|
Useful for large binaries, or for long ASCII files that aren't read by users as text, such as PostScript files.
|
|
|
|
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. Earlier revisions unaffected; see the Usage Notes for details.
|
|
|
|
The file's timestamp on the local filesystem is preserved upon submission and restored upon sync. Useful for third-party DLLs in Windows environments.
|
|
|
|
The server runs an archive trigger to access the file. See the System Administrator's Guide for details.
|
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.
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 +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.
