<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>What is Subversion?</title><link rel="stylesheet" href="styles.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><link rel="start" href="index.html" title="Version Control with Subversion" /><link rel="up" href="svn.preface.html" title="Preface" /><link rel="prev" href="svn.preface.acks.html" title="Acknowledgments" /><link rel="next" href="svn.basic.html" title="Chapter 1. Fundamental Concepts" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">What is Subversion?</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="svn.preface.acks.html">Prev</a> </td><th width="60%" align="center">Preface</th><td width="20%" align="right"> <a accesskey="n" href="svn.basic.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="svn.intro.whatis"></a>What is Subversion?</h2></div></div></div><p>Subversion is a free/open-source version control system.
That is, Subversion manages files and directories, and the
changes made to them, over time. This allows you to recover
older versions of your data, or examine the history of how your
data changed. In this regard, many people think of a version
control system as a sort of “<span class="quote">time machine</span>”.</p><p>Subversion can operate across networks, which allows it to
be used by people on different computers. At some level, the
ability for various people to modify and manage the same set of
data from their respective locations fosters collaboration.
Progress can occur more quickly without a single conduit through
which all modifications must occur. And because the work is
versioned, you need not fear that quality is the trade-off for
losing that conduit—if some incorrect change is made to
the data, just undo that change.</p><p>Some version control systems are also software configuration
management (SCM) systems. These systems are specifically
tailored to manage trees of source code, and have many features
that are specific to software development—such as natively
understanding programming languages, or supplying tools for
building software. Subversion, however, is not one of these
systems. It is a general system that can be used to manage
<span class="emphasis"><em>any</em></span> collection of files. For you, those
files might be source code—for others, anything from
grocery shopping lists to digital video mixdowns and
beyond.</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="svn.intro.righttool"></a>Is Subversion the Right Tool?</h3></div></div></div><p>If you're a user or system administrator pondering the use
of Subversion, the first question you should ask yourself is:
"is this the right tool for the job?" Subversion is a
fantastic hammer, but be careful not to view every problem as
a nail.</p><p>If you need to archive old versions of files and
directories, possibly resurrect them, or examine logs of how
they've changed over time, then Subversion is exactly the
right tool for you. If you need to collaborate with people on
documents (usually over a network) and keep track of who made
which changes, then Subversion is also appropriate. This is
why Subversion is so often used in software development
environments — programming is an inherently social
activity, and Subversion makes it easy to collaborate with
other programmers. Of course, there's a cost to using
Subversion as well: administrative overhead. You'll need to
manage a data-repository to store the information and all its
history, and be diligent about backing it up. When working
with the data on a daily basis, you won't be able to copy,
move, rename, or delete files the way you usually do.
Instead, you'll have to do all of those things through
Subversion.</p><p>Assuming you're fine with the extra workflow, you should
still make sure you're not using Subversion to solve a problem
that other tools solve better. For example, because
Subversion replicates data to all the collaborators involved,
a common misuse is to treat it as a generic distribution
system. People will sometimes use Subversion to distribute
huge collections of photos, digital music, or software
packages. The problem is, this sort of data usually isn't
changing at all. The collection itself grows over time, but
the individual files within the collection aren't being
changed. In this case, using Subversion is
"overkill".<sup>[<a id="id343320" href="#ftn.id343320" class="footnote">3</a>]</sup> There are simpler tools that
efficiently replicate data <span class="emphasis"><em>without</em></span> the
overhead of tracking changes, such as <span class="command"><strong>rsync</strong></span>
or <span class="command"><strong>unison</strong></span>.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="svn.intro.history"></a>Subversion's History</h3></div></div></div><p>
<a id="id343376" class="indexterm"></a>
In early 2000, CollabNet, Inc. (<a class="ulink" href="http://www.collab.net" target="_top">http://www.collab.net</a>) began seeking developers to
write a replacement for CVS. CollabNet offers a collaboration
software suite called CollabNet Enterprise Edition (CEE) of
which one component is version control. Although CEE used CVS
as its initial version control system, CVS's limitations were
obvious from the beginning, and CollabNet knew it would
eventually have to find something better. Unfortunately, CVS
had become the de facto standard in the open source world
largely because there <span class="emphasis"><em>wasn't</em></span> anything
better, at least not under a free license. So CollabNet
determined to write a new version control system from scratch,
retaining the basic ideas of CVS, but without the bugs and
misfeatures.</p><p>In February 2000, they contacted Karl Fogel, the author of
<em class="citetitle">Open Source Development with CVS</em>
(Coriolis, 1999), and asked if he'd like to work on this new
project. Coincidentally, at the time Karl was already
discussing a design for a new version control system with his
friend Jim Blandy. In 1995, the two had started Cyclic
Software, a company providing CVS support contracts, and
although they later sold the business, they still used CVS every
day at their jobs. Their frustration with CVS had led Jim to
think carefully about better ways to manage versioned data, and
he'd already come up with not only the name
“<span class="quote">Subversion</span>”, but also with the basic design of the
Subversion data store. When CollabNet called, Karl immediately
agreed to work on the project, and Jim got his employer, Red Hat
Software, to essentially donate him to the project for an
indefinite period of time. CollabNet hired Karl and Ben
Collins-Sussman, and detailed design work began in May. With
the help of some well-placed prods from Brian Behlendorf and
Jason Robbins of CollabNet, and Greg Stein (at the time an
independent developer active in the WebDAV/DeltaV specification
process), Subversion quickly attracted a community of active
developers. It turned out that many people had had the same
frustrating experiences with CVS, and welcomed the chance to
finally do something about it.</p><p>The original design team settled on some simple goals. They
didn't want to break new ground in version control methodology,
they just wanted to fix CVS. They decided that Subversion would
match CVS's features, and preserve the same development model,
but not duplicate CVS's most obvious flaws. And although it did
not need to be a drop-in replacement for CVS, it should be
similar enough that any CVS user could make the switch with
little effort.</p><p>After fourteen months of coding, Subversion became
“<span class="quote">self-hosting</span>” on August 31, 2001. That is,
Subversion developers stopped using CVS to manage Subversion's
own source code, and started using Subversion instead.</p><p>While CollabNet started the project, and still funds a large
chunk of the work (it pays the salaries of a few full-time
Subversion developers), Subversion is run like most open-source
projects, governed by a loose, transparent set of rules that
encourage meritocracy. CollabNet's copyright license is fully
compliant with the Debian Free Software Guidelines. In other
words, anyone is free to download, modify, and redistribute
Subversion as he pleases; no permission from CollabNet or anyone
else is required.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="svn.intro.features"></a>Subversion's Features</h3></div></div></div><p>When discussing the features that Subversion brings to the
version control table, it is often helpful to speak of them in
terms of how they improve upon CVS's design. If you're not
familiar with CVS, you may not understand all of these features.
And if you're not familiar with version control at all, your
eyes may glaze over unless you first read <a class="xref" href="svn.basic.html" title="Chapter 1. Fundamental Concepts">Chapter 1, <i>Fundamental Concepts</i></a>, in which we provide a gentle introduction
to version control.</p><p>Subversion provides:</p><div class="variablelist"><dl><dt><span class="term">Directory versioning</span></dt><dd><p>CVS only tracks the history of individual files, but
Subversion implements a “<span class="quote">virtual</span>” versioned
filesystem that tracks changes to whole directory trees
over time. Files <span class="emphasis"><em>and</em></span> directories are
versioned.</p></dd><dt><span class="term">True version history</span></dt><dd><p>Since CVS is limited to file versioning, operations
such as copies and renames—which might happen to
files, but which are really changes to the contents of
some containing directory—aren't supported in CVS.
Additionally, in CVS you cannot replace a versioned file
with some new thing of the same name without the new item
inheriting the history of the old—perhaps completely
unrelated—file. With Subversion, you can add,
delete, copy, and rename both files and directories. And
every newly added file begins with a fresh, clean
history all its own.</p></dd><dt><span class="term">Atomic commits</span></dt><dd><p>A collection of modifications either goes into the
repository completely, or not at all. This allows
developers to construct and commit changes as logical
chunks, and prevents problems that can occur when only a
portion of a set of changes is successfully sent to the
repository.</p></dd><dt><span class="term">Versioned metadata</span></dt><dd><p>Each file and directory has a set of
properties—keys and their values—associated
with it. You can create and store any arbitrary key/value
pairs you wish. Properties are versioned over time, just
like file contents.</p></dd><dt><span class="term">Choice of network layers</span></dt><dd><p>Subversion has an abstracted notion of repository
access, making it easy for people to implement new network
mechanisms. Subversion can plug into the Apache HTTP
Server as an extension module. This gives Subversion a
big advantage in stability and interoperability, and
instant access to existing features provided by that
server—authentication, authorization, wire
compression, and so on. A more lightweight, standalone
Subversion server process is also available. This server
speaks a custom protocol which can be easily tunneled over
SSH.</p></dd><dt><span class="term">Consistent data handling</span></dt><dd><p>Subversion expresses file differences using a binary
differencing algorithm, which works identically on both
text (human-readable) and binary (human-unreadable) files.
Both types of files are stored equally compressed in the
repository, and differences are transmitted in both
directions across the network.</p></dd><dt><span class="term">Efficient branching and tagging</span></dt><dd><p>The cost of branching and tagging need not be
proportional to the project size. Subversion creates
branches and tags by simply copying the project, using a
mechanism similar to a hard-link. Thus these operations
take only a very small, constant amount of time.
</p></dd><dt><span class="term">Hackability</span></dt><dd><p>Subversion has no historical baggage; it is
implemented as a collection of shared C libraries with
well-defined APIs. This makes Subversion extremely
maintainable and usable by other applications and
languages.</p></dd></dl></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="svn.intro.architecture"></a>Subversion's Architecture</h3></div></div></div><p><a class="xref" href="svn.intro.whatis.html#svn.intro.architecture.dia-1" title="Figure 1. Subversion's Architecture">Figure 1, “Subversion's Architecture”</a> illustrates
a “<span class="quote">mile-high</span>” view of Subversion's
design.</p><div class="figure"><a id="svn.intro.architecture.dia-1"></a><p class="title"><b>Figure 1. Subversion's Architecture</b></p><div class="figure-contents"><div><img src="images/ch01dia1.png" alt="Subversion's Architecture" /></div></div></div><br class="figure-break" /><p>On one end is a Subversion repository that holds all of your
versioned data. On the other end is your Subversion client
program, which manages local reflections of portions of that
versioned data (called “<span class="quote">working copies</span>”). Between
these extremes are multiple routes through various Repository
Access (RA) layers. Some of these routes go across computer
networks and through network servers which then access the
repository. Others bypass the network altogether and access the
repository directly.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="svn.intro.components"></a>Subversion's Components</h3></div></div></div><p>Subversion, once installed, has a number of different
pieces. The following is a quick overview of what you get.
Don't be alarmed if the brief descriptions leave you scratching
your head—there are <span class="emphasis"><em>plenty</em></span> more pages
in this book devoted to alleviating that confusion.</p><div class="variablelist"><dl><dt><span class="term">svn</span></dt><dd><p>The command-line client program.</p></dd><dt><span class="term">svnversion</span></dt><dd><p>A program for reporting the state (in terms of
revisions of the items present) of a working copy.</p></dd><dt><span class="term">svnlook</span></dt><dd><p>A tool for directly inspecting a Subversion repository.</p></dd><dt><span class="term">svnadmin</span></dt><dd><p>A tool for creating, tweaking or repairing a Subversion
repository.</p></dd><dt><span class="term">svndumpfilter</span></dt><dd><p>A program for filtering Subversion repository dump
streams.</p></dd><dt><span class="term">mod_dav_svn</span></dt><dd><p>A plug-in module for the Apache HTTP Server, used to
make your repository available to others over a
network.</p></dd><dt><span class="term">svnserve</span></dt><dd><p>A custom standalone server program, runnable as a
daemon process or invokable by SSH; another way to make
your repository available to others over a network.</p></dd><dt><span class="term">svnsync</span></dt><dd><p>A program for incrementally mirroring one
repository to another over a network.</p></dd></dl></div><p>Assuming you have Subversion installed correctly, you should
be ready to start. The next two chapters will walk you through
the use of <span class="command"><strong>svn</strong></span>, Subversion's command-line client
program.</p></div><div class="footnotes"><br /><hr width="100" align="left" /><div class="footnote"><p><sup>[<a id="ftn.id343320" href="#id343320" class="para">3</a>] </sup>Or as a friend puts
it, “<span class="quote">swatting a fly with a
Buick.</span>”</p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="svn.preface.acks.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="svn.preface.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="svn.basic.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Acknowledgments </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 1. Fundamental Concepts</td></tr></table></div></body></html>
