<?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>Foreword</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="index.html" title="Version Control with Subversion" /><link rel="prev" href="index.html" title="Version Control with Subversion" /><link rel="next" href="svn.preface.html" title="Preface" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Foreword</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="index.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="svn.preface.html">Next</a></td></tr></table><hr /></div><div class="preface" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="svn.foreword"></a>Foreword</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Karl</span> <span class="surname">Fogel</span></h3></div></div><div><p class="pubdate">Chicago, March 14, 2004</p></div></div></div><p>A bad Frequently Asked Questions (FAQ) sheet is one that is
composed not of the questions people actually asked, but of the
questions the FAQ's author <span class="emphasis"><em>wished</em></span> people
had asked. Perhaps you've seen the type before:</p><div class="blockquote"><blockquote class="blockquote"><p>Q: How can I use Glorbosoft XYZ to maximize team
productivity?</p></blockquote></div><div class="blockquote"><blockquote class="blockquote"><p>A: Many of our customers want to know how they can
maximize productivity through our patented office groupware
innovations. The answer is simple: first, click on the
“<span class="quote"><code class="literal">File</code></span>” menu, scroll down to
“<span class="quote"><code class="literal">Increase Productivity</code></span>”,
then…</p></blockquote></div><p>The problem with such FAQs is that they are not, in a
literal sense, FAQs at all. No one ever called the tech support
line and asked, “<span class="quote">How can we maximize
productivity?</span>”. Rather, people asked highly specific
questions, like, “<span class="quote">How can we change the calendaring system
to send reminders two days in advance instead of one?</span>”
and so on. But it's a lot easier to make up imaginary
Frequently Asked Questions than it is to discover the real ones.
Compiling a true FAQ sheet requires a sustained, organized
effort: over the lifetime of the software, incoming questions
must be tracked, responses monitored, and all gathered into a
coherent, searchable whole that reflects the collective
experience of users in the wild. It calls for the patient,
observant attitude of a field naturalist. No grand
hypothesizing, no visionary pronouncements here—open eyes
and accurate note-taking are what's needed most.</p><p>What I love about this book is that it grew out of just such
a process, and shows it on every page. It is the direct result
of the authors' encounters with users. It began with Ben
Collins-Sussman's observation that people were asking the same
basic questions over and over on the Subversion mailing lists:
What are the standard workflows to use with Subversion? Do
branches and tags work the same way as in other version control
systems? How can I find out who made a particular change?</p><p>Frustrated at seeing the same questions day after day, Ben
worked intensely over a month in the summer of 2002 to write
<em class="citetitle">The Subversion Handbook</em>, a sixty page
manual that covered all the basics of using Subversion. The
manual made no pretense of being complete, but it was
distributed with Subversion and got users over that initial hump
in the learning curve. When O'Reilly and Associates decided to
publish a full-length Subversion book, the path of least
resistance was obvious: just expand the Subversion
handbook.</p><p>The three co-authors of the new book were thus presented
with an unusual opportunity. Officially, their task was to
write a book top-down, starting from a table of contents and an
initial draft. But they also had access to a steady
stream—indeed, an uncontrollable geyser—of bottom-up
source material. Subversion was already in the hands of
thousands of early adopters, and those users were giving tons of
feedback, not only about Subversion, but about its existing
documentation.</p><p>During the entire time they wrote this book, Ben, Mike, and
Brian haunted the Subversion mailing lists and chat rooms
incessantly, carefully noting the problems users were having in
real-life situations. Monitoring such feedback was part of their
job descriptions at CollabNet anyway, and it gave them a huge
advantage when they set out to document Subversion. The book
they produced is grounded firmly in the bedrock of experience,
not in the shifting sands of wishful thinking; it combines the
best aspects of user manual and FAQ sheet. This duality might
not be noticeable on a first reading. Taken in order, front to
back, the book is simply a straightforward description of a
piece of software. There's the overview, the obligatory guided
tour, the chapter on administrative configuration, some advanced
topics, and of course a command reference and troubleshooting
guide. Only when you come back to it later, seeking the
solution to some specific problem, does its authenticity shine
out: the telling details that can only result from encounters
with the unexpected, the examples honed from genuine use cases,
and most of all the sensitivity to the user's needs and the
user's point of view.</p><p>Of course, no one can promise that this book will answer
every question you have about Subversion. Sometimes, the
precision with which it anticipates your questions will seem
eerily telepathic; yet occasionally, you will stumble into a
hole in the community's knowledge, and come away empty-handed.
When this happens, the best thing you can do is email
<code class="email"><<a class="email" href="mailto:users@subversion.tigris.org">users@subversion.tigris.org</a>></code> and present your
problem. The authors are still there, still watching, and they
include not just the three listed on the cover, but many others
who contributed corrections and original material. From the
community's point of view, solving your problem is merely a
pleasant side effect of a much larger project—namely,
slowly adjusting this book, and ultimately Subversion itself, to
more closely match the way people actually use it. They are
eager to hear from you not merely because they can help you, but
because you can help them. With Subversion as with all active
free software projects, <span class="emphasis"><em>you are not
alone</em></span>.</p><p>Let this book be your first companion.</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="index.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="svn.preface.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Version Control with Subversion </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Preface</td></tr></table></div></body></html>
