Subversion is built on a portability layer called APR (Apache Portable Runtime library). This means Subversion should work on any operating system that the Apache httpd server runs on: Windows, Linux, all flavors of BSD, Mac OS X, Netware and others.
A branch refers to a copy of an existing original tree of directories and files. A branch always begins life as a copy of something, and moves on from there, generating its own history. Branches are usually created to try out new features without disturbing the main branch of development with compiler errors and bugs.
Checking out a repository creates a copy of a desired branch on your local machine. This copy contains the latest revision of the repository that you specify.
A Commit of a file means the changes you have made on your local copy gets updated into the repository. Once a commit is made, users can see the latest version of that particular file after they do an "Update".
Sometimes, when you update your files from the repository, you may get a conflict. A conflict occurs when two or more users have changed the same few lines of a file.
A hook is a program triggered by some repository event, such as the creation of a new revision or the modification of an unversioned property. A hook is handed enough information to tell what that event is, what targets it is operating on and the username of the person who triggered the event.
A Lock refers to a mechanism which a user asks for the exclusive right to modify change a working copy file.
Merging refers to the joining together of changes made on one branch into the trunk or vice versa another branch, which may also be the trunk.
The core of Subversion is a Repository. It is a centralized system to store and share data. The repository stores information in the form of a set of trees and branches, a hierarchy of directories and files. Any number of clients can connect to the repository and read or write to these files.
In certain cases, one might need to work directly on the repository without having a working copy. This is where the repository browser comes in. It is identical to an explorer window with the icons, address bar to type in the repository URL name displayed. It also features commands like Copy, Move and Delete
Repositories can be accessed through different methods on your local disk or through network protocols. A repository location always refers to a URL. These URL's use a standard syntax that refers to the server names and port numbers to be specified.
If you decide upon examination that you want to get back the changes made to a file, you can just skip back to the previous changes by using the Revert command.
Each time the repository accepts a commit, it creates a new version of the filesystem tree called a revision. Each revision is assigned a unique number, one greater than the number of the previous revision. The initial revision of a freshly created repository is numbered zero and consists of nothing but an empty root directory.
A revision graph is a graphical representation of the location of the trunk, branches and tags going away from the trunk. It is very identical to a tree structure and is easy to view this sort of information.
When you create a new repository, it begins its life at revision zero and each successive commit increases the revision number by one. After a commit is made, the Subversion client informs you of the new revision number. Each revision number has a tree hanging below it and each tree is a snapshot of the way the repository looks after each commit.
This subcommand updates your working copy to mirror a new URL; usually a URL which shares a common ancestor with your working copy. It is the Subversion way to move a working copy to a new branch.
Tagging is basically placing a label on each file, no matter what revision number it has. This can be done either to a working copy or to the repository itself; the effects being the same.
An update synchronizes the working copy with the last changes made by any user to the repository. It fetches the latest working copies of the files to your local drive. As a thumb rule, always update a file before making any changes to it.
A working copy refers to the existing and updated copy of file(s) you have fetched from the repository. To obtain the working copy files, one needs to do a Checkout.