Storage concepts

When a user commits his changes into a Subversion repository, the changes are atomically applied to the tree stored in the repository. This produces a snapshot of the entire tree which can be referenced by its own unique id - revision number. But in fact, although each new revision may be represented as a separate tree, commit does not create a copy of the whole tree. Each revision is stored as delta against the previous revision, that is each revision contains only changes applied in that particular revision, all the rest unmodified files and directories are not cloned within the repository.

That is why hundreds and thousands of revisions is much lesser in size than just hundreds and thousands filesystem snapshots (or even archives) of the same tree.

This system tracks the history of file and directory changes over time by storing all changes in that centralized repository. All versioned files and directories reside as a tree structure (just like a general filesystem) in a Subversion repository. Both versioned files and directories can have versioned metadata - properties. Changes to such a tree are committed by clients to a repository in a single atomic transaction. Each commit operation creates a newer snapshot of the whole tree which includes all recent changes made in that commit operation as well as all previous unchanged data. Such a snapshot is called a revision. A Subversion repository starts its life from revision 0 where only the root directory exists. Then as files and directories are imported into a repository, changes to them are committed - new revisions are created, and each successful commit operation increases the revision number by one:

Subversion doesn't actually keep the whole contents in every revision. For every N-th revision it uses smart mechanisms to store only the differences that were made in that N-th revision itself (i.e. data differences between revisions N-1 and N). So, revisions allow you to retrieve any version of a file, or directory, or even of the whole tree (since a single revision is created for the whole repository tree) at any time, no changes will be lost. Each revision is a permanent snapshot of a tree, i.e. if an item is added to a Subversion repository it can not be removed from the repository entirely, because it can be always found in those revisions where it was added and changed. Although in this case item history is broken and it no longer exists in the repository starting with the revision where it's deleted. A common scenario of using a Subversion repository is working with a copy of any subtree of a repository tree on a local computer and publishing results of this work into the repository. In other words, a client somehow changes files and directories taken from a repository and then commits his\her changes into the repository. Local versioned data tree is called Working Copy (WC).

Use cases

Subversion can be used by:

What Is SVNKit For?

Generally applications have two ways of using Subversion programmatically:

According to this classification, SVNKit is a pure Java Subversion client library.

Using Subversion and SVNKit in applications

There are different kinds of applications which would like to keep the entire history of data modifications in a centralized storage (i.e. repository in our case). Subversion can give the best practice for these purposes. However all such applications (using a Subversion repository solution) can be devided into the following two groups:

The second type of applications in this list use a Subversion repository to keep their abstract model hierarchical representations. SVNKit is a programmatic solution to use version control in Java applications of both listed types. That is, SVNKit can be used as an integration tool to work with versioned data in a standard way (using WCs), or as an engine to speak to a Subversion repository on a repository access protocol layer. SVNKit provides an ability to: