[svnbook commit] r2569 - branches/ora-2e-reorg/src/en/book
cmpilato
noreply at red-bean.com
Wed Dec 20 14:16:43 CST 2006
Author: cmpilato
Date: Wed Dec 20 14:16:43 2006
New Revision: 2569
Modified:
branches/ora-2e-reorg/src/en/book/ch-introduction.xml
branches/ora-2e-reorg/src/en/book/ch-preface.xml
Log:
Branch: ora-2e-reorg
Begin the work of reorganization book sections based on our
agreed-upon outline.
* src/en/book/ch-introduction.xml
(svn.intro.whatis, svn.intro.history, svn.intro.features,
svn.intro.architecture): Move to ch-preface.xml.
* src/en/book/ch-preface.xml
(svn.intro.whatis) Moved from ch-introduction.xml as a new sect1.
(svn.intro.history, svn.intro.features, svn.intro.architecture):
Moved from ch-introduction.xml as sect2's under svn.intro.whatis.
(svn.components): New placeholder section.
Modified: branches/ora-2e-reorg/src/en/book/ch-introduction.xml
==============================================================================
--- branches/ora-2e-reorg/src/en/book/ch-introduction.xml (original)
+++ branches/ora-2e-reorg/src/en/book/ch-introduction.xml Wed Dec 20 14:16:43 2006
@@ -19,279 +19,6 @@
</simplesect>
- <!-- ================================================================= -->
- <!-- ================================================================= -->
- <!-- ================================================================= -->
- <sect1 id="svn.intro.whatis">
-
- <title>What is Subversion?</title>
-
- <para>Subversion is a free/open-source version control system.
- That is, Subversion manages files and directories over time. A
- tree of files is placed into a central
- <firstterm>repository</firstterm>. The repository is much like
- an ordinary file server, except that it remembers every change
- ever made to your files and directories. 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 <quote>time
- machine</quote>.</para>
-
- <para>Subversion can access its repository 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.</para>
-
- <para>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
- <emphasis>any</emphasis> collection of files. For you, those
- files might be source code—for others, anything from
- grocery shopping lists to digital video mixdowns and
- beyond.</para>
-
- </sect1>
-
- <!-- ================================================================= -->
- <!-- ================================================================= -->
- <!-- ================================================================= -->
- <sect1 id="svn.intro.history">
-
- <title>Subversion's History</title>
-
- <para>In early 2000, CollabNet,
- Inc. (<ulink url="http://www.collab.net"/>) began seeking
- developers to write a replacement for CVS. CollabNet offers a
- collaboration software suite called CollabNet Enterprise Edition
- (CEE)
- <footnote>
- <para>There's also a CollabNet Team Edition (CTE)
- offering aimed at smaller groups.</para>
- </footnote>
- 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 <foreignphrase>de
- facto</foreignphrase> standard in the open source world largely
- because there <emphasis>wasn't</emphasis> 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.</para>
-
- <para>In February 2000, they contacted Karl Fogel, the author of
- <citetitle>Open Source Development with CVS</citetitle>
- (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
- <quote>Subversion</quote>, but also with the basic design of the
- Subversion repository. 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.</para>
-
- <para>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.</para>
-
- <para>After fourteen months of coding, Subversion became
- <quote>self-hosting</quote> on August 31, 2001. That is,
- Subversion developers stopped using CVS to manage Subversion's
- own source code, and started using Subversion instead.</para>
-
- <para>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.</para>
-
- </sect1>
-
- <!-- ================================================================= -->
- <!-- ================================================================= -->
- <!-- ================================================================= -->
- <sect1 id="svn.intro.features">
-
- <title>Subversion's Features</title>
-
- <para>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 <xref
- linkend="svn.basic"/>, in which we provide a gentle introduction
- to version control in general.</para>
-
- <para>Subversion provides:</para>
-
- <variablelist>
- <varlistentry>
- <term>Directory versioning</term>
- <listitem>
- <para>CVS only tracks the history of individual files, but
- Subversion implements a <quote>virtual</quote> versioned
- filesystem that tracks changes to whole directory trees
- over time. Files <emphasis>and</emphasis> directories are
- versioned.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>True version history</term>
- <listitem>
- <para>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.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Atomic commits</term>
- <listitem>
- <para>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.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Versioned metadata</term>
- <listitem>
- <para>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.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Choice of network layers</term>
- <listitem>
- <para>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.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Consistent data handling</term>
- <listitem>
- <para>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.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Efficient branching and tagging</term>
- <listitem>
- <para>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.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Hackability</term>
- <listitem>
- <para>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.</para>
- </listitem>
- </varlistentry>
-
- </variablelist>
-
- </sect1>
-
- <!-- ================================================================= -->
- <!-- ================================================================= -->
- <!-- ================================================================= -->
- <sect1 id="svn.intro.architecture">
-
- <title>Subversion's Architecture</title>
-
- <para><xref linkend="svn.intro.architecture.dia-1"/> illustrates what one might
- call a <quote>mile-high</quote> view of Subversion's
- design.</para>
-
- <figure id="svn.intro.architecture.dia-1">
- <title>Subversion's Architecture</title>
- <graphic fileref="images/ch01dia1.png"/>
- </figure>
-
- <para>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 <quote>working copies</quote>). 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.</para>
-
- </sect1>
<!-- ================================================================= -->
<!-- ================================================================= -->
Modified: branches/ora-2e-reorg/src/en/book/ch-preface.xml
==============================================================================
--- branches/ora-2e-reorg/src/en/book/ch-preface.xml (original)
+++ branches/ora-2e-reorg/src/en/book/ch-preface.xml Wed Dec 20 14:16:43 2006
@@ -528,6 +528,283 @@
</sect1>
+ <!-- ================================================================= -->
+ <!-- ================================================================= -->
+ <!-- ================================================================= -->
+ <sect1 id="svn.intro.whatis">
+
+ <title>What is Subversion?</title>
+
+ <para>Subversion is a free/open-source version control system.
+ That is, Subversion manages files and directories over time. A
+ tree of files is placed into a central
+ <firstterm>repository</firstterm>. The repository is much like
+ an ordinary file server, except that it remembers every change
+ ever made to your files and directories. 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 <quote>time
+ machine</quote>.</para>
+
+ <para>Subversion can access its repository 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.</para>
+
+ <para>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
+ <emphasis>any</emphasis> collection of files. For you, those
+ files might be source code—for others, anything from
+ grocery shopping lists to digital video mixdowns and
+ beyond.</para>
+
+ <!-- =============================================================== -->
+ <sect2 id="svn.intro.history">
+
+ <title>Subversion's History</title>
+
+ <para>In early 2000, CollabNet,
+ Inc. (<ulink url="http://www.collab.net"/>) began seeking
+ developers to write a replacement for CVS. CollabNet offers a
+ collaboration software suite called CollabNet Enterprise Edition
+ (CEE)
+ <footnote>
+ <para>There's also a CollabNet Team Edition (CTE)
+ offering aimed at smaller groups.</para>
+ </footnote>
+ 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 <foreignphrase>de
+ facto</foreignphrase> standard in the open source world largely
+ because there <emphasis>wasn't</emphasis> 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.</para>
+
+ <para>In February 2000, they contacted Karl Fogel, the author of
+ <citetitle>Open Source Development with CVS</citetitle>
+ (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
+ <quote>Subversion</quote>, but also with the basic design of the
+ Subversion repository. 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.</para>
+
+ <para>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.</para>
+
+ <para>After fourteen months of coding, Subversion became
+ <quote>self-hosting</quote> on August 31, 2001. That is,
+ Subversion developers stopped using CVS to manage Subversion's
+ own source code, and started using Subversion instead.</para>
+
+ <para>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.</para>
+
+ </sect2>
+
+ <!-- =============================================================== -->
+ <sect2 id="svn.intro.features">
+
+ <title>Subversion's Features</title>
+
+ <para>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 <xref
+ linkend="svn.basic"/>, in which we provide a gentle introduction
+ to version control in general.</para>
+
+ <para>Subversion provides:</para>
+
+ <variablelist>
+ <varlistentry>
+ <term>Directory versioning</term>
+ <listitem>
+ <para>CVS only tracks the history of individual files, but
+ Subversion implements a <quote>virtual</quote> versioned
+ filesystem that tracks changes to whole directory trees
+ over time. Files <emphasis>and</emphasis> directories are
+ versioned.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>True version history</term>
+ <listitem>
+ <para>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.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Atomic commits</term>
+ <listitem>
+ <para>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.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Versioned metadata</term>
+ <listitem>
+ <para>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.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Choice of network layers</term>
+ <listitem>
+ <para>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.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Consistent data handling</term>
+ <listitem>
+ <para>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.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Efficient branching and tagging</term>
+ <listitem>
+ <para>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.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Hackability</term>
+ <listitem>
+ <para>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.</para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+
+ </sect2>
+
+ <!-- =============================================================== -->
+ <sect2 id="svn.intro.architecture">
+
+ <title>Subversion's Architecture</title>
+
+ <para><xref linkend="svn.intro.architecture.dia-1"/> illustrates what one might
+ call a <quote>mile-high</quote> view of Subversion's
+ design.</para>
+
+ <figure id="svn.intro.architecture.dia-1">
+ <title>Subversion's Architecture</title>
+ <graphic fileref="images/ch01dia1.png"/>
+ </figure>
+
+ <para>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 <quote>working copies</quote>). 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.</para>
+
+ </sect2>
+
+ <!-- =============================================================== -->
+ <sect2 id="svn.components">
+
+ <title>Subversion's Components</title>
+
+ <para>### TODO ###</para>
+
+ </sect2>
+
+ </sect1>
+
</preface>
<!--
More information about the svnbook-dev
mailing list