view release on metacpan or  search on metacpan

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

What?

"And by the way, don't try to delete a directory either."

You rolled your eyes and groaned.  How could such simple tasks be
difficult?


The Legacy of CVS
-----------------

No doubt about it, CVS has evolved into the standard Software
Configuration Management (SCM) system of the open source community.
And rightly so!  CVS itself is Free software, and its wonderful "non
locking" development model -- whereby dozens of far-flung programmers
collaborate -- fits the open-source world very well.  In fact, one
might argue that without CVS, it's doubtful whether sites like
Freshmeat or Sourceforge would ever have flourished as they do now.
CVS and its semi-chaotic development model have become an essential
part of open source culture.

So what's wrong with CVS?

Because it uses the RCS storage-system under the hood, CVS can only
track file contents, not tree structures.  As a result, the user has
no way to copy, move, or rename items without losing history.  Tree
rearrangements are always ugly server-side tweaks.

The RCS back-end cannot store binary files efficiently, and branching
and tagging operations can grow to be very slow.  CVS also uses the
network inefficiently; many users are annoyed by long waits, because
file differeces are sent in only one direction (from server to client,
but not from client to server), and binary files are always
transmitted in their entirety.

From a developer's standpoint, the CVS codebase is the result of
layers upon layers of historical "hacks".  (Remember that CVS began
life as a collection of shell-scripts to drive RCS.)  This makes the
code difficult to understand, maintain, or extend.  For example: CVS's
networking ability was essentially "stapled on".  It was never
designed to be a native client-server system.  

Rectifying CVS's problems is a huge task -- and we've only listed just
a few of the many common complaints here.


Enter Subversion
----------------

In 1995, Karl Fogel and Jim Blandy founded Cyclic Software, a company
for commercially supporting and improving CVS.  Cyclic made the first
public release of a network-enabled CVS (contributed by Cygnus
software.)  In 1999, Karl Fogel published a book about CVS and the
open-source development model it enables (cvsbook.red-bean.com).  Karl
and Jim had long talked about writing a replacement for CVS; Jim had
even drafted a new, theoretical repository design.  Finally, in
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.