Before a user can modify any of the depot files, they must create a workspace that maps specified depot files to directories on the local client machine. A user populates their workspace with copies of the depot files retrieved from the Perforce server. By default, files copied to the local workspace are read- only until you check them out.
To modify a versioned file you must first check it out. When you check out a file, Perforce changes the permissions of the file copied to the workspace from read only to read/write and adds the file information to a changelist.
When you have finished modifying a checked out file, submit the updated file to the Perforce server. The Perforce server stores the submitted file in the depot as a new revision.
Each time a user submits a set of modified files, Perforce records the changelist information in the Perforce metadata. The changelist includes:
a unique changelist identifier
the list of files that were submitted in the changelist
the date the changelist was submitted
the name of the person who submitted the changelist
the list of jobs associated with the changelist
a description of the changes that were made to the submitted files
Each changelist represents an atomic unit of change made to the depot at a unique date and time.
A complete set of changelists provides a historical record of all the changes ever made to the files in the depot. You can use a changelist identifier to define a view of the depot files based on the moment in time that the changelist was submitted.
Using the history of changes stored in the metadata, Perforce can display the revision history for a folder or for a versioned file, and can restore a file to any of its versioned states.
Because the central server manages the depot and the system metadata, Perforce easily supports collaborative development environments. Perforce can show you who is working on files in the repository.
If multiple people modify the same files simultaneously, Perforce enables you to resolve conflicts between the files.