Main

• - What Is Subversion For

• + Setting Up A Subversion Repository

• + SVNKit Architecture

• + Getting Started With SVNKit

• + Authentication

• + Managing Repository With SVNKit

  • + Printing Out A Subversion Repository Tree

  • + Printing Out File Contents

  • + Printing Out Repository History

  • + Editing operation: committing to a repository

  • + Editing Operation: receiving changes from a repository

  • + Replicating An Existing Repository

  • + Managing A Working Copy

Preface

If you're a newcomer to Subversion, we recommend you to read the official Subversion information you can find on the Subversion home site. In our articles we make references to the official 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 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 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:

attachment: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 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 [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 done 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 [http://java.sun.com 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:

• 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;
• turn contents of a repository to a portable dump format stream
• load a portable dump format stream to a repository
• examine local repositories