view release on metacpan or  search on metacpan

src/subversion/doc/user/lj_article.txt  view on Meta::CPAN

February of 2000, Brian Behlendorf of CollabNet (www.collab.net)
offered Karl a full-time job to write a CVS replacement.  Karl
gathered a team together and work began in May.

The team settled on a few simple goals: it was decided that Subversion
would be designed as a functional replacement for CVS.  It would do
everything that CVS does -- preserving the same development model
while fixing the flaws in CVS's (lack-of) design.  Existing CVS users
would be the target audience: any CVS user should be able to start
using Subversion with little effort.  Any other SCM "bonus features"
were decided to be of secondary importance (at least before a 1.0
release.)

At the time of writing, the original team has been coding for a little
over a year, and we have a number of excellent volunteer contributors.
(Subversion, like CVS, is a open-source project!)


Subversion's Features
----------------------

Here's a quick run-down of some of the reasons you should be excited
about Subversion:

  * Real copies and renames.  The Subversion repository doesn't use
    RCS files at all; instead, it implements a 'virtual' versioned
    filesystem that tracks tree-structures over time (described
    below).  Files *and* directories are versioned.  At last, there
    are real client-side `mv' and `cp' commands that behave just as
    you think.

  * Atomic commits.  A commit either goes into the repository
    completely, or not all.  

  * Advanced network layer.  The Subversion network server is Apache,
    and client and server speak WebDAV(2) to one another.  (See the
    'design' section below.)

  * Faster network access. A binary diffing algorithm is used to
    store and transmit deltas in *both* directions, regardless of
    whether a file is of text or binary type.

  * Filesystem "properties".  Each file or directory has an invisible
    hashtable attached.  You can invent and store any arbitrary
    key/value pairs you wish: owner, perms, icons, app-creator,
    mime-type, personal notes, etc.  This is a general-purpose feature
    for users.  Properties are versioned, just like file contents.
    And some properties are auto-detected, like the mime-type of a
    file (no more remembering to use the '-kb' switch!)

  * Extensible and hackable.  Subversion has no historical baggage; it
    was designed and then implemented as a collection of shared C
    libraries with well-defined APIs.  This makes Subversion extremely
    maintainable and usable by other applications and languages.

  * Easy migration.  The Subversion command-line client is very
    similar to CVS; the development model is the same, so CVS users
    should have little trouble making the switch.  Development of a
    'cvs2svn' repository converter is in progress.

  * It's Free.  Subversion is released under a Apache/BSD-style
    open-source license.


Subversion's Design
-------------------

Subversion has a modular design; it's implemented as a collection of C
libraries.  Each layer has a well-defined purpose and interface.  In
general, code flow begins at the top of the diagram and flows
"downward" -- each layer provides an interface to the layer above it.

              <<insert diagram here:  svn.tiff>>


Let's take a short tour of these layers, starting at the bottom.


--> The Subversion filesystem.  

The Subversion Filesystem is *not* a kernel-level filesystem that one
would install in an operating system (like the Linux ext2 fs.)
Instead, it refers to the design of Subversion's repository.  The
repository is built on top of a database -- currently Berkeley DB --
and thus is a collection of .db files.  However, a library accesses
these files and exports a C API that simulates a filesystem --
specifically, a "versioned" filesystem.

This means that writing a program to access the repository is like
writing against other filesystem APIs: you can open files and
directories for reading and writing as usual.  The main difference is
that this particular filesystem never loses data when written to; old
versions of files and directories are always saved as historical
artifacts.

Whereas CVS's backend (RCS) stores revision numbers on a per-file
basis, Subversion numbers entire trees.  Each atomic 'commit' to the
repository creates a completely new filesystem tree, and is
individually labeled with a single, global revision number.  Files and
directories which have changed are rewritten (and older versions are
backed up and stored as differences against the latest version), while
unchanged entries are pointed to via a shared-storage mechanism.  This
is how the repository is able to version tree structures, not just
file contents.

Finally, it should be mentioned that using a database like Berkeley DB
immediately provides other nice features that Subversion needs: data
integrity, atomic writes, recoverability, and hot backups.  (See
www.sleepycat.com for more information.)


--> The network layer.

Subversion has the mark of Apache all over it.  At its very core, the
client uses the Apache Portable Runtime (APR) library.  (In fact, this
means that Subversion client should compile and run anywhere Apache
httpd does -- right now, this list includes all flavors of Unix,
Win32, BeOS, OS/2, Mac OS X, and possibly Netware.)

However, Subversion depends on more than just APR -- the Subversion
"server" is Apache httpd itself.