[[Setting Up A Subversion Repository|>>]]
<br />
<br />

== Preface == 
If you're a newcomer to Subversion, we recommend you to read the official Subversion information 
you can find on the [http://subversion.tigris.org Subversion home site]. In our articles we make references to the 
official [http://svnbook.red-bean.com/ Subversion book] where you can find detailed information on configuring and 
utilizing a Subversion repository.

== What Is Subversion For? ==
The first question a newcomer to [http://svnbook.red-bean.com/nightly/en/index.html Subversion] may ask to himself - ''What is this and how can I use it in my work?'' 
Speaking shortly Subversion can be characterized as a version control system 
which tracks the history of file and directory changes over time. 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 [http://svnbook.red-bean.com/nightly/en/svn.tour.revs.html#svn.tour.revs.numbers 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:

[[Image:Repository_Tree.png]]

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 is 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.

<p>
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 changes into the repository. Local versioned data tree is 
called [http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.wc Working Copy] (WC).

== Use cases ==
Subversion can be used by:
* End users who manually use Subversion to keep changes to their files, etc.
* Applications which use Subversion programmatically.

== What Is SVNKit For? ==
Generally applications have two ways of using Subversion programmatically:
* Utilizing ready-to-use Subversion client programs (like a [http://svnbook.red-bean.com/nightly/en/svn.ref.html#svn.ref.svn native Subversion command line client]). Such applications have to make external calls (commands) to client programs.
* Utilizing special client libraries. 

According to this classification, '''SVNKit''' is a pure [http://java.sun.com 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:
* Those which can easily integrate with the WC format. Applications of this kind utilize versioned directories and files on a local machine.
* Those for which the '''WC''' format doesn't suit at all. Such applications work with objects\abstractions different from just files and directories. Tracking history of changes to these objects may be also very important, but Working Copy is not the case for them.
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.

<p>
'''SVNKit''' provides an ability to:
* work with a Subversion repository immediately (i.e. access data in a repository);
* create local repositories;
* operate on Working Copies;
* implement model-dependent version control formats for local data;
* replicate existing repositories;

<br />
[[Setting Up A Subversion Repository|>>]]