What is physically stored in the Perforce depot for each versioned file depends on the file's type. Perforce uses a variety of file type modifiers to identify the format of each versioned file. Some common file types include utf16, text, symlink, and binary.
When you add or open a file, Perforce client programs determine the file type by scanning a portion of the data in the file.
The server determines how to store the file using the file type information generated by the client program. If the data contained in the examined section is binary, the file is stored as a binary file. If the data contained in the examined section is textual, it is stored as a text file.
You can also manually specify the type for any file managed by Perforce.
A Perforce administrator can set up a special table linking Perforce file types to file name specifications. If a filename matches an entry in the typemap table, it overrides the file type that would otherwise have been assigned by the Perforce client program. Some examples of binary file types that might need special mapping are PDF files, which sometimes begin with over 8192 bytes of ASCII comments, and RTF files, which usually contain embedded formatting codes.
You can find out more about file types and type mapping in the Perforce documentation.
Text files are human readable. Examples of text files include, HTML pages, software application source code, XML documents, files generated by a text editor such as NotePad, and so forth.
Text files are stored in the depot in RCS reverse-delta format. An RCS reverse-delta file contains the entire contents of the most recent file revision and the differences for all prior revisions.
By backing out the changes for each previous revision, starting from the most recent revision and working back in time, Perforce can reconstruct any previous version of a text file.
Perforce identifies changes between versions of text files by comparing the files line-by-line.
The deltas stored in the RCS reverse-delta files identify the differences between the most recent revision and the newly modified file.
Unlike text files, binary files are not human readable.
Examples of binary files include, digital images, video clips, sound files, and word processing documents.
Perforce stores each version of a binary file as an individual file in a directory in the depot.
The name of the directory is derived from the original file name followed by a “comma” and the letter “d”.
Perforce also generates a unique name for each instance of the versioned binary file in the directory using the number of the changelist that included the file update.
Perforce is extensible. You can add functionality to Perforce using triggers and daemons. For example, you can configure Perforce to invoke a review daemon when files are submitted to the server.
You can use triggers to enforce processes or to integrate with other systems, for example, to enable a Defect Tracking System to generate Perforce jobs associated with defect tracker issues.
Perforce provides a set of APIs that enable you to access Perforce functions from applications that you built.