p4 opened
or p4 files
.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.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 because the client workspace always contains the file
as it was submitted.Changing a file’s type does 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 most recent n
n
revisions of the
file in the depot. If you change an existing file into a temporary
object, subsequent revisions (after the n
th) will
purge the revisions stored after the old head revision, but revisions
to the file stored in the depot before the
+S
modifier was used will remain
unaffected. (Syncing to a non-head revision submitted after
the n
+S
modifier was used will
delete the file from your workspace. Such revisions are displayed as
n
purge
operations in the output of p4 filelog
.)
p4
integrate
on temporary object files
(+S
and +Sn
) does not
produce a lazy copy. The integrated tempobj
file consumes
additional diskspace on the shared versioning service.The modtime (+m
) modifier is a special case: It is
intended for use by developers who need to preserve a file’s original
timestamp.
If a client workspace uses the modtime
option, the file
date is not guaranteed to advance for each revision. For example, if
a file is copy integrated ("accept theirs"), its timestamp will
reflect that of the source file. If a user checks in a file with an
old date, the client workspace file will reflect that same, old date.
Normally,
Perforce
updates the timestamp when a file is synced. The modtime option
enables 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
versioning service at time of submission, and not the time on
the user’s workstation 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.
If the +m
modifier on a file is
set,
when syncing
the file Perforce
restores the file’s original timestamp at the
time of submit. This means that Perforce
ignores:
modtime
("file’s timestamp at time of
submission") nomodtime
("date and time on the client
at time of sync") option setting of the client workspace Versions of Perforce prior to the year 2000 used a set of keywords to specify file types. The following table lists the older keywords and their current base file types and modifiers:
Old Keyword | Description | Base Filetype | Modifiers |
---|---|---|---|
|
Text file |
|
none |
|
Executable text file |
|
|
|
Text file with RCS keyword expansion |
|
|
|
Executable text file with RCS keyword expansion |
|
|
|
Non-text file |
|
none |
|
Executable binary file |
|
|
|
Compressed text file |
|
|
|
Compressed executable text file |
|
|
|
Symbolic link |
|
none |
|
Long text file |
|
|
|
Executable long text file |
|
|
|
Uncompressed binary file |
|
|
|
Uncompressed executable binary file |
|
|
|
Temporary object |
|
|
|
Temporary object (compressed) |
|
|
|
Temporary executable object |
|
|
|
Executable unicode |
|
|
|
Executable UTF-16 |
|
|