A new revision is created each time you make modifications to the repository.
It doesn’t matter whether you modify one or one hundred files. If you store them to the repository at the same time (using a single commit operation) then the repository’s current revision number will only increase by one.
A revision is represented by a unique number (e.g. revision 29) and identifies the exact state of all the files in the repository at the time the changes were stored (or committed) to the repository.
Large repositories can contain numerous revisions. It isn’t unusual for active repositories for large projects to contain tens of thousands of revisions.
Repositories manage all the changes made to the files they contain very efficiently. While Subversion enables you to access the complete state of the entire repository throughout its entire history, this doesn’t mean that a copy of each and every file is stored for each revision.
The BASE revision refers to the revision of a working copy file which was obtained with the last update to the working copy. Each file and folder in a working copy has its own BASE revision, as does the working copy as a whole. The BASE revision can only be altered by performing an update or commit.
The HEAD revision refers to the latest revision in the repository at any given point in time.
The WORKING revision refers to the version of a working copy file which contains any local modifications. This is distinct from BASE in that BASE always represents the version of the file without local modifications.
Subversion creates a set of files for each conflicted file. Each of these files is related to a revision relevant to resolution of the conflict.
Chief among these are the BASE and HEAD revisions. But Subversion also stores a copy of your local changes before merging them with HEAD in a file with the .mine file extension.
This is referred to in the Cornerstone user interface as the .mine version and represents the local changes made in the working copy before the conflict arose.